SQL Injection

SQL injection crosses the trust boundary between application input and executable database instructions. A vulnerable application constructs SQL by concatenating values from requests, uploaded files, messages, or previously stored records into query text. An attacker can supply input that changes the intended query logic. The resulting database operation executes with the application's database permissions, potentially exposing other customers' records or changing data that the requester should not control.

For example, an order lookup might append a request's order identifier directly to a SQL statement. If the application accepts SQL syntax instead of enforcing the expected identifier format, the resulting query may select records outside the intended order. Authentication alone does not prevent this: a signed-in user can still submit malicious input. Every relevant input source needs safe handling, including headers, cookies, background jobs, and data read back from storage.

The primary defense is parameterized queries with bound values. The application supplies a fixed SQL statement and passes user-controlled values separately, allowing the database driver to preserve the distinction between instructions and data. Object-relational mapping libraries help only when their safe query interfaces are used; raw SQL assembled through string concatenation remains vulnerable. Stored procedures are not automatically safe either, because they can construct unsafe dynamic SQL internally.

Parameters generally represent values, not table names, column names, or sort directions. When users choose a sort field, map that choice to a small set of predefined SQL identifiers rather than inserting arbitrary text. Validate types, lengths, and business constraints as additional controls. Escaping input manually is a fragile substitute for parameterization because behavior varies by database engine, character encoding, and query context.

In a cloud deployment, a web application firewall can inspect incoming HTTP requests and block patterns associated with SQL injection before requests reach the application. AWS WAF provides SQL injection match statements and managed rules that can protect supported entry points such as Amazon CloudFront distributions and Application Load Balancers. These controls provide an additional defensive layer while application vulnerabilities are repaired, but inspection limits, encoding variations, and false positives mean they cannot guarantee prevention. Test rules in count mode, review matches, and introduce narrowly scoped exceptions rather than disabling protection broadly.

Reduce the impact of a successful injection by giving each application database identity only the permissions it needs. A reporting component should not have schema-administration privileges. Keep databases off the public internet where practical and restrict database connections to authorized application components. However, private subnets and security groups do not stop malicious SQL arriving through an authorized application's existing connection. Managed database services also do not repair unsafe application queries.

For architecture exams, distinguish SQL injection from volumetric denial-of-service attacks. AWS WAF addresses HTTP request inspection, whereas AWS Shield focuses on DDoS protection and does not replace SQL injection filtering or secure coding. Encryption in transit and at rest protects data transport and storage, not query semantics. Combine parameterization, least-privilege database access, request filtering, and monitoring; correlate firewall events with application errors and supported database audit logs, while avoiding unnecessary logging of credentials or sensitive request contents.