SQL injection attacks exploit gaps between what your application is supposed to execute and what an attacker can inject. sql_firewall closes that gap at the database level by learning the exact SQL statements your application runs and blocking anything else. Unlike network-layer firewalls or application WAFs, sql_firewall operates inside the database engine, where it can inspect normalized SQL before execution.
Prerequisites
Before you begin, ensure that you have:
A PolarDB for PostgreSQL cluster running PostgreSQL 11
How it works

sql_firewall operates in three modes:
| Mode | Behavior |
|---|---|
| Learning | Records every SQL statement executed and adds it to the whitelist. No blocking or alerting occurs. |
| Permissive | Checks each statement against the whitelist. Statements not on the whitelist are still executed, but an alert is generated. |
| Enforcing | Checks each statement against the whitelist. Statements not on the whitelist are blocked and an error is returned. |
The recommended path to production is: learning → permissive → enforcing. Run in learning mode long enough for your application to exercise its full range of SQL, then validate the whitelist in permissive mode before switching to enforcing mode.
Usage notes
sql_firewallconsumes shared memory and must be loaded at cluster startup. Ifsql_firewallis not listed inshared_preload_librarieswhen the cluster starts, the extension can be created but does not work.Adding
sql_firewalltoshared_preload_librariesrequires a cluster restart. Plan this change during a maintenance window.The
sql_firewall.firewallparameter is not visible in the console. Contact Alibaba Cloud support to change its value.sql_firewall_reset()andsql_firewall_stat_reset()can only be called when enforcing mode is disabled. Switch away from enforcing mode before running these functions.
Configure shared_preload_libraries in the PolarDB console. For details, see Specify cluster parameters.
Set up sql_firewall
Step 1: Load the library
Add sql_firewall to the shared_preload_libraries parameter in the PolarDB console, then restart the cluster.
Step 2: Create the extension
CREATE EXTENSION sql_firewall;Step 3: Enable learning mode
Contact Alibaba Cloud support to set sql_firewall.firewall to learning, then restart the cluster.
Run your application normally for a representative period — long enough to cover your full range of SQL workloads. The extension records every statement it sees and adds it to the whitelist.
How long should you run in learning mode? Run long enough to cover all code paths your application exercises: routine queries, batch jobs, scheduled tasks, and any workflows that run infrequently. A learning period that misses legitimate statements will cause false positives in enforcing mode.
Step 4: Switch to permissive mode
Set sql_firewall.firewall to permissive and restart the cluster.
In this mode, statements not on the whitelist are still executed, but alerts are generated. Review the alerts and determine whether flagged statements are legitimate:
If a statement is legitimate, switch back to learning mode temporarily to add it to the whitelist.
If a statement looks like an attack, note it for investigation.
Before switching to enforcing mode, confirm that the alert rate has dropped to near zero during normal application operation. Residual alerts in permissive mode become blocked queries in enforcing mode.
Step 5: Switch to enforcing mode
Set sql_firewall.firewall to enforcing and restart the cluster.
In enforcing mode, any statement not on the whitelist is blocked. The cluster is now protected against SQL injection.
If a legitimate statement is blocked after switching to enforcing mode, switch back to permissive mode, let the application run the statement (it will be logged as a warning), then switch to learning mode briefly to add it to the whitelist. Return to enforcing mode when ready.
Switch modes
Modify the sql_firewall.firewall parameter and restart the cluster to switch modes.
Valid values:
| Value | Effect |
|---|---|
disable | Disables the extension entirely |
learning | Enables learning mode |
permissive | Enables permissive mode |
enforcing | Enables enforcing mode |
The sql_firewall.firewall parameter is not displayed in the console. Contact support to modify it.
Functions and views
Management functions
| Function | Description | Requirements |
|---|---|---|
sql_firewall_reset() | Clears the whitelist | Requires the polar_superuser role; enforcing mode must be disabled |
sql_firewall_stat_reset() | Deletes statistics | Requires the polar_superuser role; enforcing mode must be disabled |
Views
sql_firewall.sql_firewall_statements
Returns all SQL statements in the whitelist, along with the number of times each statement has been executed.
sql_firewall.sql_firewall_stat
Returns two counters:
sql_warning: the number of alerts generated in permissive modesql_error: the number of errors returned in enforcing mode
Remove sql_firewall
DROP EXTENSION sql_firewall;Examples
Permissive mode
The following example shows how sql_firewall behaves in permissive mode. The whitelist contains one statement. Three queries are then run against a table named k1.
-- Check the current whitelist: one statement has been learned
SELECT * FROM sql_firewall.sql_firewall_statements;
WARNING: Prohibited SQL statement
userid | queryid | query | calls
--------+------------+---------------------------------+-------
10 | 3294787656 | select * from k1 where uid = 1; | 1
(1 row)
-- Whitelisted statement: executes normally, no warning
SELECT * FROM k1 WHERE uid = 1;
uid | uname
-----+-------------
1 | Park Gyu-ri
(1 row)
-- Whitelisted statement (same query, different parameter): executes normally
-- sql_firewall normalizes parameters, so uid = 3 matches the same whitelist entry
SELECT * FROM k1 WHERE uid = 3;
uid | uname
-----+-----------
3 | Goo Ha-ra
(1 row)
-- SQL injection attempt (OR 1 = 1 is an always-true condition that returns all rows)
-- Not on the whitelist: executes but triggers a WARNING
SELECT * FROM k1 WHERE uid = 3 OR 1 = 1;
WARNING: Prohibited SQL statement
uid | uname
-----+----------------
1 | Park Gyu-ri
2 | Nicole Jung
3 | Goo Ha-ra
4 | Han Seung-yeon
5 | Kang Ji-young
(5 rows)In permissive mode, the injection attempt executes and returns all rows, but the WARNING signals that the statement is not on the whitelist.
Enforcing mode
The following example shows the same queries in enforcing mode. Whitelisted statements run normally; the injection attempt is blocked before execution.
-- Whitelisted statement: executes normally
SELECT * FROM k1 WHERE uid = 3;
uid | uname
-----+-----------
3 | Goo Ha-ra
(1 row)
-- SQL injection attempt: blocked with an ERROR, no data returned
SELECT * FROM k1 WHERE uid = 3 OR 1 = 1;
ERROR: Prohibited SQL statementIn enforcing mode, the injection attempt is blocked before execution. No data is returned.