Detects SQL injection patterns in incoming requests and blocks them before they reach the backend. Inspects query parameters, the request path, form and JSON bodies (and optionally headers) against a set of detection rules transpiled from the OWASP Core Rule Set (CRS) REQUEST-942 SQL-injection rules.
The rule set is bundled; no download or configuration is required. The level attribute selects the CRS paranoia level (1 = aggressive, low false positives; 4 = paranoid). Set onDetect to warn to log detections without blocking while tuning a deployment.
Requests and responses are both inspected: when reached in the request flow the request is checked, when reached in the response flow the response is checked. Because Membrane can also act as an outbound (egress/forward) gateway, inspecting responses guards untrusted upstreams and stops SQL error fragments leaking back to clients. Scope it to one direction by placing it inside a request or response flow element.
Scanning is not free: the message body is read into memory and matched against every active rule. Cost grows with body size and paranoia level. Pair this plugin with a limit plugin placed before it, so oversized bodies are rejected before they are buffered and scanned:
- limit:
maxBodyLength: 100000
- sqlInjectionProtection:
level: 1
This is a defense-in-depth filter, not a complete guarantee. Signature-based detection can be bypassed and always carries a false-positive risk; it does not replace parameterized queries (prepared statements) in the backend, which remain the primary protection against SQL injection.
The detection rules are derived from the OWASP Core Rule Set (Apache-2.0). See https://coreruleset.org/ .
Syntax
sqlInjectionProtection:
inspectHeaders: <boolean>
level: <number>
onDetect: blocksqlInjectionProtection: inspectHeaders: <boolean> level: <number> onDetect: block
Attributes
| Name | Required | Default | Description | Examples |
|---|---|---|---|---|
| inspectHeaders | false | false | Whether headers are inspected. Applies to the message being scanned: request headers in the request flow, response headers (e.g. from an untrusted upstream behind an outbound gateway) in the response flow. Off by default because legitimate headers (User-Agent, Referer, Set-Cookie, ...) trigger false positives more readily than parameters. | - |
| level | false | 1 | CRS paranoia level (1-4). Higher levels enable more rules: more aggressive detection at the cost of more false positives. Level 1 is recommended for most APIs. | - |
| onDetect | false | block | What to do on detection: block rejects a detected request with HTTP 400 and a detected response with HTTP 502; warn only logs, allowing the message through (useful while tuning). | - |