# SQL Injection and Database Security: Risks Between Application and Database **URL:** https://securesys.com.tr/en/learning/database-security/sql-injection-and-database-security ![SQL Injection and Database Security: Risks Between Application and Database](/images/bilgi-merkezi/covers/cover-veritabani-06.webp) SQL Injection is one of the most critical vulnerabilities that has been known for years yet can still lead to serious data breaches in web applications, API services and corporate software. This vulnerability most often arises at the application layer. However, its effect is seen directly on the database. For this reason SQL Injection must be a shared subject not only for the software development team but also for; the database administrator, DevSecOps, the SOC, the Red Team, the Blue Team, application security and the information security teams. If an application does not process the user input it receives from outside safely, the attacker can change the logic of the SQL query. As a result; unauthorized data viewing, data modification, authentication bypass, sensitive information leakage and in some cases broader system effects can arise. For this reason, against SQL Injection, merely saying: **“We use a WAF.”** or: **“We do input validation.”** is not sufficient. The secure approach; **Parameterized Query, Prepared Statement, Least Privilege, Secure Coding, Input Validation, ORM Security, Error Handling, WAF, Logging and Database Monitoring** requires these controls to be applied together. ### What Is SQL Injection? SQL Injection is the vulnerability where, because the application includes user input in the SQL query in an unsafe way, the query logic can be manipulated. The core problem is this: **Data and SQL command have not been separated from each other.** While the data coming from the user should be processed only as data, it becomes a part of the SQL query. ### What Is SQL? SQL is: #### Structured Query Language the query language used to communicate with relational databases. With SQL; data can be read, added, updated, deleted and database objects can be managed. ### Why Is SQL Injection Dangerous? Because the web application most often reaches the database on the user's behalf. If the application does not build the SQL query safely, the attacker can abuse the database privileges the application holds. The critical point here: **The impact of SQL Injection can grow as large as the privileges of the application database account.** ### Is SQL Injection an Application Vulnerability? Yes. The vulnerability generally arises inside the application code. However, the result appears on the database. For this reason the database security team must be concerned with this risk too. ### How Does SQL Injection Arise? Fundamentally it arises because user input is concatenated directly into the SQL query. For example, the application; a username, a search term, a product id can add inputs such as these directly into the SQL statement instead of using safe parameters. In that case the attacker can influence the query logic. ### What Is the Fundamental Root Cause of SQL Injection? The most fundamental root cause is the: #### Untrusted Input + Dynamic SQL combination. ### What Is Untrusted Input? It is data coming from the user or from an external system that must not be considered safe. For example; a URL parameter, an HTTP header, a form field, a JSON body, a cookie, an API input can be untrusted input. ### Are Only Form Fields Risky? No. SQL Injection does not arise only in a username/password form. The risk; search, filter, sort, report, API, mobile backend, admin panel can be present at many points such as these. ### What Is Second-Order SQL Injection? Malicious or unexpected data is first recorded into the database as normal data. Later another operation uses this data inside dynamic SQL in an unsafe way. In that case the vulnerability emerges at the later stage. ### What Is Blind SQL Injection? It is the type of SQL Injection where the application does not show the database response directly but inferences about the query result can be made from behavioural differences. The important point from a defence perspective is this: **Not showing the error message does not eliminate SQL Injection.** ### What Is Error-Based SQL Injection? They are the scenarios where database error messages can give the attacker information about the query or the structure. For this reason detailed database error messages must not be shown to the user in a production environment. ### Is Authentication Bypass Possible with SQL Injection? It can be in unsafe authentication queries. For this reason parameterized queries must be used in login systems too. ### Can Data Be Read with SQL Injection? Sensitive data can come under risk to the extent of the application database account's SELECT privileges. ### Can Data Be Changed with SQL Injection? If the application account holds UPDATE or DELETE privileges the risk can increase. For this reason Least Privilege carries critical importance. ### What Determines the Impact of SQL Injection? The main factors: - Application account privileges - Database configuration - Network access - Stored procedure privileges - DBMS features - The logging and monitoring level - The application architecture ### What Happens If the Application Account Is a DBA? The impact of SQL Injection can become far greater. For this reason the web application account must not be a DBA or superuser if there is no requirement for it. ### How Does Least Privilege Protect Against SQL Injection? It does not eliminate the vulnerability. However, it limits the impact of the attack. For example, if the application can only SELECT on certain tables, the area the attacker can reach shrinks. ### What Is Defense in Depth? SQL Injection security must not be provided with a single control. Example: #### Secure Coding ↓ #### Parameterized Query ↓ #### Input Validation ↓ #### WAF ↓ #### Application Account Least Privilege ↓ #### Database Audit ↓ #### DAM / SIEM This structure creates different defence layers. ### What Is a Parameterized Query? A Parameterized Query separates the SQL command from the user data. The user input is processed not as SQL syntax but only as data. It is one of the most fundamental defence methods against SQL Injection. ### What Is a Prepared Statement? It is the method in which the SQL query is prepared in advance and the parameters are bound separately. It supports the same security principle as a parameterized query. ### What Is Parameter Binding? It is the safe binding of user input to the parameters in the SQL query. This way the input cannot change the query structure. ### Why Is String Concatenation Risky? Combining user input with an SQL string creates risk. It must be avoided particularly in dynamic query generation. ### What Is Dynamic SQL? It is the SQL query being built as a string at runtime. In some cases it can be necessary. However, when used together with user input, safe design is required. ### Should Dynamic SQL Be Banned Entirely? It is not always possible. However, parameterized and allow-list-based methods must be used as far as possible. ### Does Input Validation Prevent SQL Injection? On its own it is not sufficient. Input validation is an important additional control. The main defence must be the parameterized query. ### What Is Allow-List Validation? It is accepting only the expected values. For example, the sort order can only be; ASC or DESC as its value. In that case not every string coming from the user is accepted. ### What Is Deny-List Validation? It is the approach of blocking certain characters or words. On its own it is not reliable. Because the attacker can use different encoding or syntax methods. ### Why Is an Allow-List Safer? It defines the set of expected values. Everything unknown is rejected. This is a more controlled model. ### Is Escaping Enough for SQL Injection? Not always. Depending on the DBMS, the encoding and the context, escaping errors can arise. The parameterized query must be the safer approach. ### What Is an ORM? ORM is: #### Object Relational Mapping the software layer providing abstraction between application objects and database tables. ### Does an ORM Automatically Prevent SQL Injection? No. An ORM can provide parameterization when used correctly. However, if the developer uses raw SQL or string concatenation, SQL Injection can still arise. ### What Is Raw SQL? It is writing the SQL query directly instead of using the ORM. If raw SQL is to be used it needs to be parameterized. ### Is the ORM Query Builder Safe? When safe APIs are used the risk drops. However, adding a dynamic filter or a raw fragment requires care. ### Does a Stored Procedure Prevent SQL Injection? It does not prevent it automatically. User input must be used safely inside the stored procedure. ### Is Dynamic SQL Inside a Stored Procedure Risky? Yes. If the input is added directly into the SQL string, the same risk continues. ### Can a Stored Procedure Provide a Security Advantage? Yes. Instead of giving the application direct table permissions, only the privilege to run certain procedures can be granted. ### What Is the EXECUTE-Only Model? It is the application running only the permitted stored procedures instead of reaching the tables directly. This can reduce the attack surface. ### Is Least Privilege Necessary for Stored Procedures? Yes. The procedure must not run with more privileges than it needs. ### SQL Injection and API Security In modern systems backend APIs reach the database. For this reason SQL Injection is no longer merely a classic web form problem. REST API, GraphQL resolver, microservice risk can arise at layers such as these too. ### Can JSON Input Cause SQL Injection? Yes. If a string value inside the JSON is added directly into the SQL query, risk can arise. ### Is GraphQL Safe Against SQL Injection? GraphQL on its own does not prevent SQL Injection. How the backend resolver builds the database query is what determines it. ### Does a Mobile Application Carry SQL Injection Risk? Yes. The mobile application's backend API can contain SQL Injection. Moreover, the use of a local database on the device must be designed safely too. ### Does a Microservice Architecture Reduce SQL Injection Risk? Automatically, no. Every microservice must apply the same secure development principles in its own database access layer. ### Does the Database-per-Service Model Provide an Advantage? It can reduce the blast radius. When one microservice is compromised there may be no direct access to the other databases. ### Is a Shared Database Risky in a Microservice Architecture? Many services using the same database and the same credential can enlarge the impact of the attack. ### Should the Service Account Be Separate for Every Microservice? As far as possible, yes. This provides both Least Privilege and Audit. ### Does a WAF Prevent SQL Injection? A WAF can detect and block many SQL Injection patterns. However, it is not the main solution. ### Why Is a WAF Not Sufficient on Its Own? Because; encoding, obfuscation, business logic, API structure because of these, some attacks can get past the detection mechanism. Moreover, a WAF does not fix the vulnerability in the application code. ### What Is WAF Virtual Patching? It is the method of temporarily blocking certain attack patterns until the application vulnerability is fixed. ### Is a Virtual Patch a Permanent Solution? No. The permanent solution is fixing the source code. ### What Is RASP? RASP is: #### Runtime Application Self-Protection the security approach that tries to detect or block suspicious behaviour while the application is running. ### Can RASP Help with SQL Injection? Yes. However, it does not take the place of secure coding and parameterization. ### What Is a Database Firewall? It is the security layer that analyses the queries going to the database. ### Can a Database Firewall Detect SQL Injection? It can detect some anomalies or banned query patterns. ### Can DAM Be Used in SQL Injection Detection? Yes. Database Activity Monitoring can show unusual query behaviour. ### Is a SQL Injection Incident Visible in the Database Logs? If appropriate audit and logging exist it can be seen. However, if the logging level is insufficient, finding the detail of the incident can be difficult. ### Which Logs Matter for SQL Injection? For example: Web server logs Application logs WAF logs Database audit logs DAM logs SIEM events can be analysed together. ### How Does the SOC Monitor SQL Injection? The SOC can correlate events coming from different sources. For example: WAF → Suspicious request Application → SQL error spike Database → Unusual query DAM → Bulk table read SIEM → Correlated incident ### What Is a SQL Error Spike? Far more database syntax or query errors than normal arising can be an indicator of an attack attempt or an application bug. ### Is Failed Query Monitoring Useful? Yes. Many unusual query errors arising in a short time in particular can be investigated. ### Can Sensitive Table Access Be an Indicator of SQL Injection? If it does not match the normal application behaviour, yes. ### How Can Bulk Data Extraction Be Detected? Far more rows than normal being read or a large response being created can be monitored. ### What Is a Query Baseline? It is the profile of the query behaviour the application normally executes. ### Can Query Allow-Listing Be Used? In some high-security environments the expected query patterns can be defined. However, careful design is required in dynamic applications. ### Should the Database Account Be Restricted by Source IP? Yes. The application account must be able to connect only from the application servers. ### Should the Application Account Be Able to Connect from a User Laptop? Generally no. This account must be used only from the relevant application infrastructure. ### How Should the Application Database Credential Be Stored? It must not be kept hard-coded inside the source code. A secret manager or vault can be used. ### Can Credentials Be Obtained After SQL Injection? If there are secrets stored wrongly inside the database or in the application configuration, the impact can grow. For this reason sensitive secrets must not be kept in plaintext inside the database. ### Should Passwords Be Kept Inside the Database? User passwords must be kept with a secure password hashing method. Reversible plaintext or simple encryption is not suitable. ### SQL Injection and Password Hash Leakage If access to the user table is obtained, password hashes can leave the organization. For this reason the quality of the password hashing matters too. ### The Relationship Between SQL Injection and Data Classification If it is known which tables hold sensitive data, access to those tables can be monitored more closely. ### How Are Sensitive Database Tables Determined? With data discovery and classification; PII, payment, health, credential, financial the tables containing such data can be flagged. ### Can Sensitive Table Access Generate an Additional Alarm? Yes. For example, if the application does not normally reach this table, an unexpected query can create an alarm. ### SQL Injection and Row-Level Security RLS can provide an additional defence layer. Even if the application account is compromised, the user can see only certain rows. ### SQL Injection and Column-Level Security It can restrict the user's access to sensitive columns. ### Does Dynamic Data Masking Protect Against SQL Injection? It does not solve the vulnerability. However, it can reduce the amount of sensitive data some users see. ### The Relationship Between SQL Injection and Encryption TDE provides no protection against SQL Injection. Because the database returns a plaintext response to a normal query. ### Can Column Encryption Help? If the encryption key is held at the application layer, it can make the ciphertext obtained through the database harder to make sense of directly. ### Can Application-Level Encryption Reduce the Impact of SQL Injection? Yes. On very sensitive fields in particular, a separate cryptographic boundary can provide an advantage. ### Is There a Relationship Between SQL Injection and Backup Security? Indirectly there is. If the attacker corrupts data on the database, a secure backup is needed for recovery. ### Can SQL Injection Break Data Integrity? If the application account holds write privileges, yes. In that case Integrity is affected. ### Why Can Point-in-Time Recovery Be Important? If the moment at which the faulty or malicious data change occurred is known, the database can be returned to the earlier time. ### Is a Restore Always Enough After SQL Injection? No. The root cause of the attack must be closed first. Otherwise the restored system can be affected again. ### How Should Incident Response Be Considered in a SQL Injection Incident? The general defence flow: Detection ↓ Containment ↓ Application Investigation ↓ Database Activity Analysis ↓ Credential Review ↓ Impact Assessment ↓ Code Remediation ↓ Validation ↓ Recovery ### Which Questions Should Be Asked After SQL Injection? Which endpoint was affected? Which database account was used? Which privileges did the account hold? Which tables were reached? Was data changed? Was an export performed? Did credentials leak? How long had the vulnerability existed? ### How Is It Determined Whether SQL Injection Turned into a Data Breach? Database audit, DAM, application logs, network logs are examined in an effort to determine the scope of the data reached. ### What Happens If There Is No Audit? Determining the incident scope can become very difficult. For this reason logging is as critical as preventive security. ### Are SQL Injection and Ransomware the Same Thing? No. However, if the attacker's access on the application and the database broadens, data integrity or availability can be affected. ### Is There a Relationship Between SQL Injection and Insider Threat? Just as the vulnerability can be used by an external attacker, it can also be abused by an authorized user inside. ### What Is the Secure Software Development Lifecycle – SSDLC? It is security being included in every stage of the software lifecycle. ### Where Should SQL Injection Be Addressed Within the SSDLC? Requirements, design, development, code review, testing, deployment it must be considered at all of these stages. ### What Is a Secure Coding Standard? They are the secure software development rules developers will follow. In terms of SQL Injection, for example: Parameterized queries are mandatory. Raw dynamic SQL is restricted. Hard-coding secrets is forbidden. rules such as these can be defined. ### Can Code Review Detect SQL Injection? Yes. The code building database queries in particular must be reviewed. ### What Is SAST? SAST is: #### Static Application Security Testing which analyses the source code for security vulnerabilities without running it. ### Can SAST Find SQL Injection? It can detect some taint flow and query construction problems. However, there can be false positives and false negatives. ### What Is DAST? DAST is: #### Dynamic Application Security Testing which tests the running application from the outside. ### Is DAST Used in SQL Injection Detection? Yes. Signs of SQL Injection can be looked for at web and API input points. ### What Is IAST? IAST is: #### Interactive Application Security Testing which analyses the runtime together with the test traffic while the application is running. ### Which Is Better, SAST or DAST? They are not alternatives to each other. When used together they can provide stronger coverage. ### Does SCA Find SQL Injection? SCA analyses third-party dependency risks more than anything else. It does not aim to find custom SQL Injection code directly. ### Is a Penetration Test Necessary for SQL Injection? SQL Injection checks can be performed during web application and API pentests. However, a pentest does not take the place of a secure SDLC. ### Should Code Review and Pentesting Be Used Together? Yes. Code review can find the root cause. A pentest, meanwhile, can assess the real exposure on the running system. ### Can a CI/CD Pipeline Reduce SQL Injection Risk? If security tests are integrated into the pipeline, vulnerabilities can be detected before production. ### How Does DevSecOps Approach SQL Injection? For example: Developer IDE security plugin ↓ Secure Code Review ↓ SAST ↓ Unit Security Test ↓ DAST/API Test ↓ Production WAF/DAM/SIEM a layered process along these lines can be established. ### What Is a Security Unit Test? They are the automated tests verifying that certain inputs do not break the query construction behaviour. ### Why Is Regression Testing Important? It helps prevent a previously closed SQL Injection vulnerability from arising again after a new code change. ### What Is a False Positive? It is the security tool flagging as a vulnerability a situation that is in fact not one. ### What Is a False Negative? It is the security tool failing to detect a real vulnerability. For this reason a single tool must not be relied upon. ### Why Is Developer Security Training Important? The permanent solution to SQL Injection is most often a source code fix. The developer must know how to build safe queries. ### Do Developers Using an ORM Need to Know SQL? Yes. An ORM provides abstraction, but understanding the underlying database behaviour matters for security and performance. ### Should the Database DBA and the Developer Work Together? Yes. The DBA; permissions, stored procedures, performance contributes in these areas. The developer, meanwhile, manages the application logic. ### Why Is Cooperation Between AppSec and the DBA Important? AppSec detects the vulnerability. The DBA assesses the database account privileges and the possible impact. ### How Is SQL Injection Risk Severity Determined? Not only the existence of the vulnerability but; the data reached, application account privilege, internet exposure, data classification, exploitability factors such as these must be looked at. ### Can CVSS Be Used for SQL Injection? Yes. It can be used in the technical severity assessment. However, the business impact must be assessed separately. ### SQL Injection and Business Impact For example; SQL Injection in a public product catalogue and SQL Injection reaching the customer finance database do not carry the same business impact. ### What Is Risk-Based Remediation? It is prioritizing vulnerabilities according to business impact and technical severity. ### How Quickly Must a Critical SQL Injection Be Closed? It must be addressed as quickly as possible according to the organization's vulnerability management SLA. Internet-facing vulnerabilities reaching sensitive data can be given the highest priority. ### What Is a Compensating Control for SQL Injection? If the permanent fix cannot be made immediately, temporarily; a WAF rule, endpoint restriction, account privilege reduction, monitoring can be applied. However, source code remediation must still be done. ### SQL Injection and the API Gateway An API Gateway; authentication, rate limiting, request validation can provide these. However, it does not automatically guarantee the backend's SQL query security. ### Does Rate Limiting Prevent SQL Injection? No. However, it can reduce the speed of automated attack attempts. ### Does Authentication Prevent SQL Injection? No. An authenticated endpoint can contain SQL Injection too. ### Is an Internal Application Exempt from SQL Injection? No. Internal applications can also be targeted by a compromised user or an insider. ### Is the “It Is Not Exposed to the Internet, So It Is Safe” Approach Correct? No. Network location alone is not a security guarantee. ### What Does Zero Trust Mean for SQL Injection? It means the application not reaching the database with unlimited trust, and minimum privilege and continuous monitoring being applied. ### What Is a Database Query Timeout? It can help terminate very long-running queries after a defined period. ### Is Query Timeout a Security Control? It is not a direct SQL Injection prevention control. However, it can reduce the effect of resource exhaustion. ### Can a Resource Governor Be Used? On some platforms it can be used to limit a user's or a workload's CPU and resource consumption. ### Can SQL Injection Create a DoS Effect? Yes. Heavy queries can consume database resources and affect availability. ### Why Is the Connection Limit Important? Excessive connections because of the application or an attack can consume database resources. ### SQL Injection and Query Cost Monitoring Queries far more costly than normal can be assessed as an anomaly. ### How Should Database Error Handling Be Done? A generic error message must be shown to the user. Detailed database errors must be kept in server-side logs. ### Should the Stack Trace Be Shown to the User? In a production environment, generally no. It can leak framework, path, SQL and internal system information. ### Should the Database Name Be Shown to the User? Unnecessary information disclosure must be reduced. ### Should the SQL Error Log Be Turned Off Entirely? No. It must not be shown to the user, but secure internal logging must be done. ### Can Sensitive Data Be Held in the Logs? Care must be taken. SQL query logs can contain passwords, tokens or personal data. ### What Is Log Masking? It is the masking of the sensitive fields inside the log. ### Does a Prepared Statement Solve Every Type of SQL Injection? It is very strong for data parameters. However, parameterizing SQL structural elements such as table name, column name or sort direction is not always possible. An allow-list must be used in these areas. ### How Is a Dynamic Table Name Managed Safely? The table name must not be taken directly from the user. The application must map the permitted options internally. ### Is the ORDER BY Parameter Risky? If it is controlled by the user it can create dynamic SQL risk. An allow-list must be used. ### Does Pagination Carry SQL Injection Risk? Page, limit or offset values must be validated and parameterized safely. ### Is a Search Filter Risky? Yes. Advanced search screens in particular generate many dynamic queries. ### Why Is the Reporting Module Critical for SQL Injection? They are the areas where dynamic filters, sorting and complex query usage are heaviest. ### Is Admin Panel SQL Injection Riskier? Admin accounts can hold broad application functions. However, the database account privilege must still be kept minimal. ### Multi-Tenant Database SQL Injection Risk One customer reaching another customer's data is a serious isolation problem. ### How Is Tenant Isolation Strengthened? Alongside the application logic; Row-Level Security, a separate schema, a separate database models such as these can be used. ### Should the Tenant ID Be Considered Trusted from the User? No. Authorization must be verified server-side. ### Are SQL Injection and IDOR the Same? No. SQL Injection is a query manipulation vulnerability. IDOR, meanwhile, is an authorization problem. However, both can lead to unauthorized data access. ### Are SQL Injection and Command Injection the Same? No. SQL Injection targets database queries. Command Injection is an operating system command execution risk. ### What Is NoSQL Injection? It is the similar class of injection that can arise on NoSQL systems such as MongoDB through manipulation of the query object or filter. ### Is a Parameterized Query Important for NoSQL Too? Safe query APIs must be used according to the NoSQL technology. ### Doesn't Using an ORM Automatically Solve NoSQL Injection Too? No. User input being passed uncontrolled into the query object can still create risk. ### A Corporate Checklist Against SQL Injection The organization must assess these controls: - Parameterized Query - Prepared Statement - Input Allow-List - Secure ORM Usage - Dynamic SQL Review - Least Privilege - Separate Application Account - No DBA Privilege for Applications - Secret Management - WAF - API Security - SAST - DAST - Code Review - Database Audit - DAM - SIEM - Sensitive Data Monitoring - Secure Error Handling - Security Testing ### Developer SQL Injection Checklist The developer must ask these questions: Is user input being added into an SQL string? Is a parameterized query being used? Is dynamic SQL really necessary? Is there an allow-list on sort/filter fields? Is raw SQL being used? Is the database error being shown to the user? Is the application account more privileged than it needs to be? ### DBA SQL Injection Checklist From the DBA's perspective: Is the application account a DBA? Which tables can it read? Does it hold the DROP privilege? Are the stored procedure privileges correct? Do connections come only from the application server? Is audit active? Is sensitive table access monitored? ### SOC SQL Injection Checklist From the SOC's perspective: Are WAF alerts monitored? Are SQL error spikes detected? Does the database audit reach SIEM? Is there a bulk data query alarm? Are application account anomalies monitored? ### Questions Management Should Ask About SQL Injection Corporate leaders must know the answers to these questions: Do our internet-facing applications go through regular security testing? Do developers use parameterized queries? Are our application database accounts least-privileged? What is our SLA for closing a SQL Injection when it is found? Do we have database audit logs? If data is pulled through a SQL Injection, can we detect it? When was the last pentest performed? ### Frequently Asked Questions #### What is SQL Injection? It is the vulnerability where the query logic can be changed because user input is included in the SQL query in an unsafe way. #### Is SQL Injection a database vulnerability? It generally arises in the application code but its effect appears on the database. #### How is SQL Injection prevented? The most fundamental method is using a Parameterized Query or a Prepared Statement. #### Is input validation enough? No. Parameterization must be the main control. #### Does an ORM prevent SQL Injection? Used correctly it reduces the risk, but the vulnerability can still arise because of raw or dynamic SQL. #### Does a WAF fully prevent SQL Injection? No. A WAF is an additional security layer; it does not take the place of a source code fix. #### Does TDE protect against SQL Injection? No. TDE protects the data on disk. Authorized database queries can obtain plaintext data. #### Should the application account be a DBA? In most cases absolutely not. The minimum privilege principle must be applied. #### Is SQL Injection found by pentesting? Yes, SQL Injection tests can be performed in web and API pentests. However, it does not take the place of secure coding and continuous security testing. #### What should be done after SQL Injection? The vulnerability must be closed, the scope of access must be investigated, database logs must be examined, and the credential and data impact must be assessed. ### Conclusion: The Impact of SQL Injection Is Determined as Much by Database Privileges as by Application Code SQL Injection is most often seen as a software development problem. But in reality this vulnerability sits on the boundary between: #### Application Security and #### Database Security as its home. If the application does not build safe queries, the vulnerability arises. If the database account is more privileged than it needs to be, the impact of the vulnerability grows. If there is no logging, determining what happened after the attack becomes difficult. If there is no monitoring, the attack can go unnoticed for a long time. For this reason the real defence against SQL Injection is the: #### Parameterized Query #### Least Privilege #### Secure Coding #### WAF #### Database Audit #### DAM/SIEM approach. The most critical principle is this: **User input must never be considered trusted as an SQL command.** The application must separate input from query syntax. The database, meanwhile, must give the application only the privileges it genuinely needs. When these two approaches are applied together, not only is the likelihood of SQL Injection arising reduced; even if a vulnerability does emerge, the blast radius of the attack can be limited considerably. From a corporate perspective the right question is not: **“Is there SQL Injection in our application?”** but instead; **“If SQL Injection emerges in one of our applications, which database, with which account, which data and with how much privilege can be reached?”** this question. The answer given to this question shows the real level of database security.