Test SQL Injection for CRA Compliance

Testing for SQL injection isn’t just a technical best practice anymore; it’s a critical compliance mandate. For manufacturers selling products in the European Union, a single SQL injection (SQLi) flaw can trigger serious regulatory consequences under the Cyber Resilience Act (CRA), making proactive testing a non-negotiable part of your go-to-market strategy.

Why the CRA Mandates SQL Injection Testing

SQL injection is far more than a simple coding mistake—it’s a direct threat to data integrity and system control. The EU’s Cyber Resilience Act (CRA) views this technical vulnerability as a major compliance risk, pushing manufacturers from a reactive to a proactive security stance. If you ignore this, you’re essentially gambling with your access to the entire EU market.

The regulation’s whole point is to make sure products with digital elements are secure by design. A vulnerability as old and well-understood as SQL injection completely undermines that principle. For example, if a smart home hub’s web interface allows an attacker to manipulate its underlying database, they could potentially disable security features or extract user data. This is why thorough SQL injection testing is so essential.

The High Stakes of a Critical Class Designation

Under the CRA, products get categorised based on their potential risk. A single, severe vulnerability like SQL injection can be enough to land your product in the “Critical Class” under Annex III.

That label is a big deal. It sets off a chain reaction of stringent new obligations, including:

• Mandatory Third-Party Audits: Your product will have to go through—and pass—a conformity assessment from an external notified body.
• Intensive Security Requirements: You’ll need to implement and document advanced security measures that go far beyond standard expectations.
• Strict Reporting Timelines: Any vulnerabilities you discover must be reported to authorities like ENISA within 24 hours.

Failing to meet these tougher requirements means your product is barred from the EU market. The costs of fixing the issue, paying for audits, and potentially redesigning your product after it’s been flagged as Critical Class will dwarf the investment in doing robust testing upfront. You can dig deeper into the regulation’s core principles in our guide to the Cyber Resilience Act.

Real-World Breaches and Financial Consequences

The threat of SQLi isn’t just theoretical. It remains a stubbornly persistent and damaging attack vector across the European cybersecurity landscape. A classic example is the high-profile Bulgarian government data breach, where attackers used SQL injection flaws to steal sensitive citizen data from official systems. For a manufacturer under the CRA, a similar bug in a connected device could easily trigger that dreaded Critical Class designation.

The financial and reputational damage from breaches like these can be huge. Beyond the regulatory fines, companies face a loss of customer trust, legal battles, and massive costs for incident response and system clean-up. Proactively finding and squashing these flaws is a direct investment in your company’s financial health and brand.

To better align your testing efforts with CRA expectations, it’s helpful to structure them around the regulation’s core pillars.

SQLi Testing Focus Areas for CRA Compliance

Testing Focus Area	Common Vulnerable Components	Relevant CRA Obligation
Web Interfaces & APIs	Login forms, search fields, parameterised API endpoints, admin panels	Annex I, Section 1(3)(d) – Protection against unauthorised access
Firmware & Embedded Systems	Device configuration interfaces, data synchronisation services, local storage APIs	Annex I, Section 1(3)(e) – Protection of data confidentiality and integrity
Update Mechanisms	Update servers, package managers, firmware download endpoints	Annex I, Section 1(3)(f) – Limiting attack surfaces
Third-Party Components	Open-source libraries, commercial SDKs, database drivers	Annex I, Section 2(1) – Coordinated vulnerability handling and SBOM

This table maps out where to concentrate your SQL injection testing efforts to directly address specific CRA mandates. Focusing on these areas ensures your validation activities generate the evidence needed for your technical file.

A robust vulnerability management programme is no longer just a nice-to-have for mature security teams. For CRA compliance, it’s a non-negotiable prerequisite for market access. Your ability to discover, document, and remediate flaws like SQL injection is central to building a compliant technical file.

To see how these requirements fit into the bigger picture of compliance, it’s worth looking at guides that cover broader security assessments, such as those detailing SOC 2 Penetration Testing Requirements. This context helps place CRA mandates within the wider compliance ecosystem. The message is clear: regulators expect rigorous, evidence-based security validation, and SQL injection testing is a cornerstone of that expectation.

Setting Up A Safe And Authorised Assessment

Diving straight into payload injection without groundwork is a fast track to mistakes. A solid preparation phase isn’t optional—it’s essential for a legal, safe and reliable SQL injection test. Skip it, and you risk service outages, legal headaches or tests that tell you nothing.

First, you must define a clear scope. Know exactly which applications, endpoints and databases you’re allowed to probe. Without that, you’ll either accidentally push past your remit or miss critical attack surfaces entirely.

Defining Scope And Gaining Authorisation

Treat your scope document like a contract, not a casual memo. It should clearly list every target, for example:

• Web Application URLs: https://portal.myproduct.com, https://api.myproduct.com
• IP Ranges: 10.0.1.0/24 for embedded-device endpoints
• Databases, APIs and supporting services: MySQL instance on db.test.internal, REST API at /api/v2/*

Then, get that document signed off. You need explicit, written permission from the system owner or an authorised executive. An email is the bare minimum; a formal sign-off is better. That paper trail protects you and your organisation if something goes sideways.

Never start a security assessment based on a verbal agreement. Written authorisation is your single most important legal protection and ensures everyone are aligned on objectives and boundaries.

With clear authorisation in hand, choose your playground wisely. Live production systems are far too risky—an unexpected query can corrupt data or take your service offline. Instead, spin up an isolated test environment that mirrors production in software versions, configurations and architecture.

If you need more details on building that sandbox safely, see our guide on how to test SQL injection vulnerabilities without putting live systems at risk.

Below is a diagram showing how even a single SQLi flaw triggers mandatory testing under regulations like the CRA.

This flow makes it clear that a minor code lapse leads straight to compliance obligations for regulated products.

Assembling Your Testing Toolkit

Once your lab environment is live, gather the tools you’ll rely on. A mix of automated and manual utilities gives you the broadest coverage:

• Interception Proxy: Burp Suite or OWASP ZAP lets you capture, inspect and tweak HTTP requests in real time. For example, intercepting a login request to change the password parameter to an SQLi payload.
• Automated Scanner: sqlmap crawls targets and flags hundreds of potential injection points for deeper review. It can automate the entire process from detection to data exfiltration.
• Command-Line Utilities: curl or similar tools help you script custom requests and poke at device APIs. For example: curl -X POST -d "query=' OR 1=1--" http://api.test.com/search.

A well-organised toolkit lets you shift seamlessly from broad scans to focused, manual probing. That blend of automation and hands-on finesse ensures you uncover—and verify—every hidden vulnerability.

Going Hands-On with Manual SQL Injection Testing

Automated scanners are great for catching low-hanging fruit and giving you broad coverage, but they’ll almost always miss the subtle, context-specific flaws. That’s where a human touch becomes essential. To really get under the skin of an application, you have to start thinking like an attacker—probing with the same creativity and persistence they would.

Manual testing is less of a science and more of an art. It starts with mapping out every single place a user can provide input. Don’t just look at the obvious login forms. Think bigger: URL parameters, API endpoints, hidden form fields, cookies—each one is a potential door into the database.

Probing with Classic Payloads

The easiest place to start is with tautologies, which are just SQL expressions that are always true. These classic payloads are designed to trick the application’s logic, often to bypass authentication or convince the database to return more data than it should.

Take a typical user login form. The backend query probably looks something like this:
SELECT * FROM users WHERE username = '[INPUT_USERNAME]' AND password = '[INPUT_PASSWORD]';

An attacker can use a simple, elegant payload to walk right past this check.

• Payload: ' OR 1=1 --
• How It Works: Inject this into the username field, and the query morphs into SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '...';. The OR 1=1 forces the WHERE condition to be true for every row. The double-hyphen (--) is a SQL comment, which tells the database to ignore everything that follows, including the password check.
• Successful Response: You’re logged in without a valid password, often as the first user in the database table—which, more often than not, is an administrator.

This technique is surprisingly effective against older systems or applications without proper input sanitisation. It’s a foundational check I run before digging any deeper.

Uncovering Flaws with Error-Based Injection

When an application is misconfigured to show raw database errors to users, it’s like leaving the architectural blueprints on the front lawn. Error-based SQL injection is all about intentionally crafting bad queries to trigger these revealing error messages.

Imagine a URL that pulls up product details, like .../getProduct.php?id=123. The query behind it might be SELECT name, desc FROM products WHERE id = 123;.

By tinkering with that id parameter, you can make the database spill its secrets.

• Payload: 123' AND 1=CONVERT(int, @@version) --
• How It Works: This payload tries to convert the database version string (e.g., “Microsoft SQL Server 2019…”) into a whole number. This will obviously fail, and if the application is vulnerable, the resulting error message gets printed right on the page.
• Successful Response: You see an error like, “Conversion failed when converting the nvarchar value ‘Microsoft SQL Server…’ to data type int.” This not only confirms the vulnerability but also tells you exactly what backend technology you’re dealing with.

This kind of direct feedback is a goldmine. It allows an attacker to quickly map out the database schema and plan their next move.

Mastering Blind SQL Injection Techniques

So, what happens when an application does the right thing and suppresses detailed error messages? This is when you have to get sneaky with blind SQL injection techniques. These methods are much slower, relying on tiny, indirect clues from the application’s response to piece together information.

There are two main flavours of blind SQL injection:

• Boolean-Based: You ask the database a series of true/false questions and watch to see if the page content changes. For instance, does .../product?id=123 AND 1=1 load a normal page while .../product?id=123 AND 1=2 returns something different? A practical example is guessing a database name character by character: .../product?id=123 AND SUBSTRING(database(),1,1)='a'. If the page loads normally, the first letter is ‘a’.
• Time-Based: You tell the database to pause for a few seconds if a certain condition is true. If the server’s response suddenly takes longer, you know your condition was met.

Let’s try a time-based attack on a product search feature.

• Payload: search_term' AND (SELECT 1 FROM (SELECT(SLEEP(5)))a) --
• How It Works: This payload injects a subquery that instructs the database to literally SLEEP for 5 seconds. If the application is vulnerable and runs the query, the entire HTTP response will be delayed by that amount of time.
• Successful Response: The webpage hangs for about five seconds longer than usual before loading. This is your confirmation that you can execute commands, even if you can’t see any direct output.

Manual testing, especially blind injection, is a game of patience. It’s an iterative process of asking tiny questions and carefully observing the answers. This is exactly how you find the vulnerabilities that automated tools, which are built on predictable patterns, will almost always miss.

The consequences of missing these flaws can be devastating. Just look at the 2015 TalkTalk breach in the UK. Attackers used an SQL injection vulnerability to get their hands on millions of customer records, resulting in a £400,000 fine from the ICO for basic security failures. This case is a stark reminder of the financial and reputational wreckage a single SQLi flaw can cause and underscores the importance of understanding common threats like those detailed in the OWASP Top Ten.

Relying on manual testing alone is a surefire way to miss things, especially when you’re up against a massive attack surface. It’s essential for finding those tricky, logic-based flaws, but it just doesn’t scale. This is where automated tools come in—they are absolutely indispensable for getting broad coverage quickly.

Think of a good scanner as your first line of attack. It can crawl countless web pages and API endpoints, systematically probing every input it finds with a massive library of attack payloads. This frees you up from the grunt work, letting you focus your expertise on the more complex vulnerabilities the scanner might hint at. For any serious security assessment, automation gives you the breadth you need to make sure nothing obvious slips through the cracks.

Integrating Sqlmap into Your Workflow

When it comes to open-source tools to test sql injection vulnerabilities, sqlmap is one of the most respected and effective options out there. It’s a command-line workhorse that automates almost the entire process of finding and exploiting SQL injection flaws. Its real power is its huge feature set and its ability to work with a massive range of database management systems.

Getting started is as simple as pointing it at a URL, but the real magic happens when you start using its command-line flags to fine-tune the scan. This is how you get both accuracy and efficiency.

Here’s a glimpse of the sqlmap interface, which runs entirely from the command line to perform its scans.

The screenshot shows the tool’s help menu, which gives you a sense of just how customisable these scans can be—from specifying targets to choosing injection techniques and fingerprinting the database.

A good starting point for a basic, but thorough, scan might look something like this:

sqlmap -u "http://testphp.vulnweb.com/listproducts.php?cat=1" --batch --level=3 --risk=3

Let’s quickly break down what this command is actually doing:

• -u "URL": This is the most basic part—it just tells sqlmap what to target.
• --batch: This is a lifesaver for scripting. It tells sqlmap to run with default behaviours and not stop to ask for input.
• --level=3: This cranks up the intensity. By default, sqlmap runs at level 1. Pushing it to 3 makes the scan much more comprehensive, telling it to test things like cookies and other headers.
• --risk=3: This flag increases the aggressiveness of the payloads. Higher risk levels might try queries that modify data, so you should only ever use this on a non-production system where you have explicit permission.

This combination gives you a deep, aggressive scan—perfect for a dedicated test environment where you’re authorised to be disruptive. To see how tools like this fit into a bigger picture, our guide on Dynamic Application Security Testing offers more context.

Interpreting Results and Avoiding Pitfalls

As powerful as automated scanners are, they’re not perfect. You have to approach their results with a healthy dose of scepticism. They’re notorious for generating false positives—flagging a vulnerability that isn’t actually there. The real skill is using the scanner’s output as a road map for your own manual verification.

Never, ever take an automated report at face value. If sqlmap flags a potential time-based blind SQL injection, your very next step should be to fire up a tool like Burp Suite or curl and try to confirm it yourself. Can you reliably reproduce that time delay? This manual validation is what separates a real threat from scanner noise.

The data backs up this balanced approach. A recent analysis shows SQLi is still a major threat, even if its prevalence has dipped slightly. Aikido’s 2025 analysis found that 6.7% of open-source and 10% of closed-source vulnerabilities are SQLi. In fact, over 20% of the closed-source projects they scanned were vulnerable at first. While SQLi’s share in those projects dropped by 17% from 2023–2024, the total number of related CVEs went up, which tells us the risk is still very much alive. You can find more insights on the state of SQL injections on Aikido’s blog.

Automation gives you speed and scale, but manual validation provides the certainty required for effective remediation and compliance reporting. The combination of both is the hallmark of a mature security testing programme.

Ultimately, automated tools are force multipliers. They take care of the repetitive, time-sucking discovery work, which lets security professionals apply their expertise where it really counts: confirming complex flaws, assessing the business impact, and helping developers build more secure code.

Documenting Findings for Remediation and Compliance

Finding a SQL injection vulnerability is a huge win, but your work is only half done. Without clear, comprehensive documentation, your discovery is just an observation that risks getting lost in a backlog. Proper reporting is what turns that finding into an actionable task for developers and a critical piece of evidence for your Cyber Resilience Act (CRA) technical file.

This isn’t about pointing fingers; it’s about creating a clear roadmap for remediation. The goal is to give your development team everything they need to understand, reproduce, and ultimately fix the flaw. This documentation also serves as a formal audit trail, demonstrating your organisation’s commitment to proactive vulnerability management—a core tenet of the CRA.

Building an Effective Vulnerability Report

A strong vulnerability report is structured, precise, and easy to follow. Think of it as a technical guide written specifically for your internal team. To get this crucial step right, you can lean on powerful software documentation tools that help organise and present these complex findings clearly.

Your report absolutely must contain a few key elements to be effective:

• A Clear and Concise Title: It should immediately identify the vulnerability type and its location. Something like, “Time-Based Blind SQL Injection in Product Search API Endpoint.”
• The Affected Endpoint: Pinpoint the exact vulnerable component. This could be a URL, an API endpoint, or a specific function within the device’s firmware.
• A Detailed Description: Briefly explain what a SQL injection is and the specific impact in this context. For instance, explain how it could lead to unauthorised data access or even a full database compromise.
• Step-by-Step Reproduction Guide: This is the most critical part. List the exact steps, including the specific payloads used, to reproduce the vulnerability. Any ambiguity here will only slow down the remediation process.

Illustrating the Impact with Practical Examples

Let’s walk through a practical example of how to document a blind SQL injection finding.

Affected Endpoint:
https://api.exampleproduct.com/v1/devices/search

Reproduction Steps:

1. Send a POST request to the endpoint with a standard JSON body.
2. Note the normal response time (e.g., ~300ms).
3. Now, modify the deviceName parameter in the JSON body with the following time-based payload:
   

   {
     "deviceName": "MyDevice' AND (SELECT 1 FROM (SELECT(SLEEP(5)))a) --"
   }
   

   
   
4. Send this modified request and watch the server’s response time.
5. Result: The API response is now delayed by approximately 5 seconds, confirming the application executed the SLEEP() command. This is hard proof the endpoint is vulnerable to a time-based blind SQL injection.

This level of detail leaves zero room for interpretation. A developer can take this and instantly verify the finding on their own machine.

Assigning Risk and Providing Remediation Guidance

Once you’ve proven the vulnerability exists, you need to quantify its risk. The Common Vulnerability Scoring System (CVSS) is the industry standard for this. A CVSS calculator helps you generate a score from 0 to 10 based on metrics like attack vector, complexity, and impact on confidentiality, integrity, and availability. This score is vital for helping prioritise the bug fix among other development tasks.

Your report should not only identify the problem but also propose the solution. Providing actionable remediation advice is essential for bridging the gap between security and development teams.

Finally, offer clear, actionable guidance on how to fix it. Avoid generic advice like “fix the SQL injection.” Get specific:

• Primary Recommendation: Refactor the database query to use parameterised statements (often called prepared statements). If you can, provide a code snippet in the relevant programming language showing exactly how to implement this. For example, in Java with JDBC:
  

  String query = "SELECT * FROM products WHERE name = ?";
  PreparedStatement stmt = connection.prepareStatement(query);
  stmt.setString(1, productName);
  ResultSet rs = stmt.executeQuery();
  

  
  
• Secondary Recommendation: Implement robust, server-side input validation to ensure user-supplied data conforms to expected formats and types. Make it clear that this is a defence-in-depth measure, not a substitute for parameterised queries.

By following this structured approach, you create a complete vulnerability report that not only helps developers fix the issue efficiently but also builds the robust documentation required to demonstrate CRA compliance.

Common Questions About SQL Injection Testing

As your team starts weaving security assessments into your development workflow, a few questions always pop up. Getting these sorted out early helps everyone—from engineering to compliance—get on the same page about how to properly test for SQL injection, what to look for, and how often to do it.

Nailing down these details is the key to building a repeatable testing programme that not only strengthens your security but also satisfies tough regulatory demands like the Cyber Resilience Act (CRA).

How Often Should We Test for SQL Injection Vulnerabilities?

The short answer? Continuously. In modern development, this means automated security scanning tools should be a standard part of your CI/CD pipeline. These tools are great at catching the low-hanging fruit and common SQLi patterns before a line of code even makes it to a staging environment.

But automation alone isn’t enough. A layered approach is what really works in practice:

• Annually: Get a fresh pair of eyes on your application with a comprehensive, manual penetration test. This can be done by your internal experts or, even better, a specialised third-party firm.
• Post-Release: After any major code change, especially one that adds new features that talk to the database, run targeted tests. New code means new potential attack surfaces.
• Continuously: Keep your automated tools—like Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST)—running as part of your day-to-day development lifecycle.

For CRA compliance, this kind of consistent, ongoing vulnerability identification is non-negotiable. It proves to regulators you’re actively managing your product’s security long after it’s been released.

What Is the Difference Between Blind and Error-Based SQLi?

The real difference comes down to one thing: the feedback an attacker gets from the application. This single distinction completely changes how you approach testing.

Error-based SQLi is the more obvious of the two. It happens when you send a dodgy query, and the database throws an error message that gets displayed right on the webpage. For example, injecting a single quote (') into a URL parameter might result in a page showing Syntax error near ''' in query. This is a goldmine for an attacker, giving them direct clues about database versions, table names, and query structures, which makes exploitation much faster.

On the other hand, blind SQLi is a much stealthier and more painstaking technique. It’s used when the application is smart enough to hide database errors. Since you can’t see any direct output, you have to get creative. Testers essentially have to ask the database a long series of true/false questions and watch for subtle changes in the application’s response, like a time delay (time-based) or a tiny difference in the page content (boolean-based).

Can a Web Application Firewall Prevent All SQL Injection Attacks?

No, absolutely not. A Web Application Firewall (WAF) is a critical layer of defence, but you should never rely on it as your only solution. A well-tuned WAF is brilliant at blocking a huge range of known SQLi attack patterns, but it’s not a silver bullet.

A WAF is a valuable compensating control, but it treats the symptom, not the cause. The only true fix for a SQL injection vulnerability is secure coding within the application itself.

A determined attacker will eventually find clever ways to bypass WAF rules using different encoding or obfuscation tricks. For example, a WAF might block OR 1=1, but an attacker could bypass it with a more complex payload like OR 'a'='a'. The only robust security strategy is defence-in-depth. Use your WAF as a shield, but make sure you eliminate the actual vulnerability in the application code by using parameterised queries and strict input validation every single time.

---

Navigating the complexities of CRA compliance requires a clear, structured approach. Regulus provides a unified platform to assess your obligations, generate a tailored requirements matrix, and build the technical documentation needed to confidently place your products on the EU market. Learn how Regulus can simplify your CRA compliance journey.