OWASP Top 10 attack categories
SQL injection occurs when user-supplied input is included directly in a database query without proper handling. If an attacker enters a carefully crafted string into a login form, they might manipulate the query logic to bypass authentication or extract every record from the database. The fix is parameterized queries (also called prepared statements), which separate the SQL command structure from the user data so that input can never be interpreted as SQL code.
Cross-site scripting (XSS) injects malicious scripts into web pages viewed by other users. A stored XSS attack saves the malicious script in the database so it runs for every user who views the affected page. The attacker's script runs in the victim's browser in the context of the vulnerable site, allowing credential theft, session hijacking, or malicious redirects. The fix is output encoding: convert special characters like less-than and greater-than signs into their HTML entity equivalents so browsers display them rather than executing them.
Insecure Direct Object Reference (IDOR) exposes internal implementation objects (database IDs, file paths) directly to users. If an application uses a URL like /invoice?id=1234 and a user can change 1234 to 1235 to access another user's invoice, that is IDOR. The fix is server-side authorization checks that verify the requesting user has permission to access the specific object before returning it.
Cross-site request forgery (CSRF) tricks authenticated users into submitting requests they did not intend. A malicious page contains a form or link that, when loaded, sends a legitimate-looking request to another site where the user is already authenticated. The fix is anti-CSRF tokens: unique secret values included in forms that the server validates before processing the request.
Security testing methods and secure SDLC
SAST (Static Application Security Testing) analyzes source code, bytecode, or binaries without executing the application. It runs early in the development cycle, often integrated into the IDE or the CI/CD pipeline. SAST can identify SQL injection vulnerabilities, hard-coded credentials, and buffer overflows directly in the code before any test environment is needed. The limitation is false positives: SAST tools flag potential issues that are not actually exploitable in context.
DAST (Dynamic Application Security Testing) tests the running application by sending inputs and analyzing responses. It simulates what an attacker would do: probing inputs, manipulating requests, observing error messages. DAST finds vulnerabilities that SAST misses because they only appear at runtime. The limitation is coverage: DAST only tests what it can reach and may miss code paths not exercised by its probes.
Shifting security left means integrating security activities early in the Software Development Lifecycle rather than bolting them on at the end. Threat modeling during design, SAST during development, DAST during testing, and security requirements from the start all cost less than fixing vulnerabilities after deployment.
How to choose the correct answer
Input validation prevents injection attacks: whitelist allowed input characters and formats, reject or sanitize anything that does not match. Parameterized queries prevent SQL injection specifically.
SAST: analyzes code without running it, finds issues early, some false positives. DAST: tests the running application, finds runtime issues, limited by test coverage.
Attack identification: user input manipulating SQL query = SQL injection. Malicious script in webpage output = XSS. Accessing another user's resources by changing an ID = IDOR. Forged cross-site request = CSRF.
Output encoding: converts special characters so browsers display them rather than executing them. Prevents XSS.
Anti-CSRF tokens: server-generated unique values included in forms and validated server-side. Prevents CSRF.