{"id":17666,"date":"2026-08-01T10:31:51","date_gmt":"2026-08-01T09:31:51","guid":{"rendered":"https:\/\/www.milesweb.co.uk\/hosting-faqs\/?p=17666"},"modified":"2026-08-01T10:31:51","modified_gmt":"2026-08-01T09:31:51","slug":"block-sql-injection-using-waf","status":"publish","type":"post","link":"https:\/\/www.milesweb.co.uk\/hosting-faqs\/block-sql-injection-using-waf\/","title":{"rendered":"How to Block SQL Injection Using a WAF | Setup Guide"},"content":{"rendered":"\n

SQL Injection (SQLi) is one of the oldest and most dangerous vulnerabilities in web applications<\/a>. This happens when an attacker injects malicious SQL code into an input field (such as a login box or search bar), which prompts the back-end database to execute commands it wasn\u2019t designed to execute.<\/p>\n\n\n\n

A Web Application Firewall (WAF) sits between your users and your web application, examining incoming HTTP\/HTTPS traffic. It can detect and block SQL injection attacks before they reach your application\/database.<\/p>\n\n\n\n

This article describes what SQL injection is, how a WAF prevents it, and guides you through the configuration of SQLi protection step by step.<\/p>\n\n\n\n

Useful Read: A Complete Guide to SQL Injection<\/a><\/strong><\/p>\n\n\n\n

What is SQL Injection?<\/h2>\n\n\n\n

SQL injection is when a user-supplied input is concatenated into a SQL query without proper validation or sanitization. <\/p>\n\n\n\n

Example of a vulnerable query:<\/strong><\/p>\n\n\n\n

SELECT * FROM users WHERE username = '$username' AND password = '$password';<\/em><\/strong><\/code><\/pre>\n\n\n\n
Malicious input:<\/strong><\/p>\n\n\n\n
username = admin' --<\/em><\/strong><\/code><\/pre>\n\n\n\n
Resulting query:<\/strong><\/p>\n\n\n\n
SELECT * FROM users WHERE username = 'admin' -- 'AND password = '';<\/em><\/strong><\/code><\/pre>\n\n\n\n
Here, — starts a SQL comment, causing the database to ignore the rest of the query. As a result, the password check is bypassed, potentially allowing the attacker to log in as the admin user without knowing the password.<\/p>\n\n\n\n
Popular SQLi attack types:<\/h3>\n\n\n\n
    \n
  1. Classic\/In-band SQLi:<\/strong> The attacker can directly see the results (e.g., error messages, page content).<\/li>\n\n\n\n
  2. Blind SQLi: <\/strong>The attacker infers data from true\/false or timing responses.<\/li>\n\n\n\n
  3. Union-based SQLi: <\/strong>Combination of results from another table using the UNION operator.<\/li>\n\n\n\n
  4. Out-of-band SQLi:<\/strong> Data is leaked via DNS or HTTP requests.<\/li>\n<\/ol>\n\n\n\n
    What is a WAF and How Does it Prevent SQLi?<\/h2>\n\n\n\n
    A WAF operates at Layer 7, the application layer. It looks at each request that comes in\u2014headers, cookies, query strings, form data, and JSON bodies and matches it to a set of rules or patterns.<\/p>\n\n\n\n
    Useful Read: <\/strong>What Is A Web Application Firewall?<\/strong><\/a><\/p>\n\n\n\n
    For SQL injection specifically, a WAF utilizes the following:<\/h3>\n\n\n\n
      \n
    1. Signature-based detection: <\/strong>Matches known SQLi patterns (e.g., UNION SELECT, OR 1=1, –, xp_cmdshell).<\/li>\n\n\n\n
    2. Anomaly scoring: <\/strong>Assigns risk scores to suspicious tokens (e.g., too many quotes, SQL keywords) and blocks requests if a threshold is exceeded.<\/li>\n\n\n\n
    3. Regular expressions \/ grammar-based parsing: <\/strong>Some modern WAFs parse the input as if it were SQL to more accurately detect injection attempts than simple regex.<\/li>\n\n\n\n
    4. Rate-based and behavioral rules: <\/strong>Repeated probing attempts typical of automated SQLi scanners, such as sqlmap, are flagged.<\/li>\n<\/ol>\n\n\n\n
      WAF can do the following when a request matches a rule:<\/h3>\n\n\n\n
        \n
      • 403 Forbidden (Block the request)<\/li>\n\n\n\n
      • Log it for review.<\/li>\n\n\n\n
      • Challenge the request (e.g., CAPTCHA).<\/li>\n\n\n\n
      • Rate limit source IP<\/li>\n<\/ul>\n\n\n\n
        Before You Start: Prerequisites<\/h2>\n\n\n\n
        Before you start to block SQL injection using WAF, ensure you have the following setup ready. <\/p>\n\n\n\n
          \n
        • Access to the WAF admin interface (cloud or self-hosted)<\/li>\n\n\n\n
        • A staging\/test environment (preferred before applying rules to production)<\/li>\n\n\n\n
        • Understanding of your application\u2019s traffic patterns (to prevent false positives)<\/li>\n\n\n\n
        • Your list of public-facing endpoints and forms that take user input<\/li>\n<\/ul>\n\n\n\n
          Enable SQL Injection Protection: A Step-by-Step Guide<\/h2>\n\n\n\n
          Here are the configuration steps you can follow for the most popular WAF platforms. Choose the one that fits your environment.<\/p>\n\n\n\n
          Option A: AWS WAF<\/h3>\n\n\n\n
            \n
          • To get started, open the AWS WAF & Shield Console.<\/li>\n\n\n\n
          • Create a new Web ACL or use an existing one, and associate it with your resource (CloudFront, ALB, API Gateway, or AppSync).<\/li>\n\n\n\n
          • Under Rules, choose Add rules > Add managed rule groups.<\/li>\n\n\n\n
          • Enable the AWS Managed Rules \u2013 SQL Database (SQLi) rule group (AWSManagedRulesSQLiRuleSet).<\/li>\n\n\n\n
          • Change the rule group action to Block.<\/li>\n\n\n\n
          • (Optional) You can use the SqliMatchStatement to define a custom rule to inspect specific fields, such as the body, query string, or custom headers.<\/li>\n\n\n\n
          • Save and deploy the web ACL.<\/li>\n<\/ul>\n\n\n\n
            Before moving to Block mode, review CloudWatch metrics and sampled requests over a few days in Count mode to catch false positives.<\/p>\n\n\n\n
            Option B: Cloudflare WAF (Web Application Firewall)<\/h3>\n\n\n\n
              \n
            • Log in to the Cloudflare dashboard and choose your domain.<\/li>\n<\/ul>\n\n\n\n
              Security -> WAF -> Managed Rules<\/em><\/strong><\/p>\n\n\n\n
                \n
              • Activate the Cloudflare Managed Ruleset. It comes with rules for detecting SQL injection.<\/li>\n\n\n\n
              • Set the SQLi-related rules’ sensitivity\/action to Block (Cloudflare allows per-rule action overrides).<\/li>\n\n\n\n
              • (Optional) Create a Custom Rule:\n
                  \n
                • Field: <\/strong>URI query string, body, or specific form field<\/li>\n\n\n\n
                • Operator: <\/strong>Use or include the built-in SQLi detection expression:<\/li>\n\n\n\n
                • (cf.waf.score.sqli < 30)<\/em><\/strong><\/li>\n\n\n\n
                • Action:<\/strong> Block<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                • Deploy first in log mode, review the Security Events dashboard, then switch to block.<\/li>\n<\/ul>\n\n\n\n
                  Testing Your WAF Rules<\/h2>\n\n\n\n
                  Once you configure your WAF protection, testing is essential. It ensures all the steps are correctly executed to protect you.<\/p>\n\n\n\n
                    \n
                  • Safe payloads to use only in testing environments:<\/strong><\/li>\n<\/ul>\n\n\n\n
                    ' OR '1'='1\n1; DROP TABLE users--\n' UNION SELECT null, null--\nadmin'--<\/code><\/pre>\n\n\n\n
                      \n
                    • How to test:<\/strong><\/li>\n<\/ul>\n\n\n\n
                        \n
                      1. Submit the payloads through login forms, search boxes, or URL parameters in a non-operational environment. <\/li>\n\n\n\n
                      2. Ensure that your WAF returns a 403 Forbidden (or whatever block response you have configured) instead of a normal application response. <\/li>\n\n\n\n
                      3. Check your WAF logs to see if SQLI was flagged.<\/li>\n\n\n\n
                      4. Optionally, you can test using an automated scanner like sqlmap:<\/li>\n<\/ol>\n\n\n\n
                        sqlmap -u \"https:\/\/staging.example.com\/login\" --data=\"username=test&password=test\" --batch<\/em><\/strong><\/code><\/pre>\n\n\n\n
                        The WAF should prevent or exert a great deal of control over sqlmap’s probing behavior. Never conduct these tests on production systems or systems not owned by you.<\/p>\n\n\n\n