🔒 AppSec & Secure Code Review Language

Parameterised queries (prepared statements) separate SQL structure from user data — user input is always a parameter, never part of the SQL text.

Vulnerable (string concatenation):

String query = "SELECT * FROM users WHERE email = '" + email + "'";
// If email = "' OR '1'='1", the query becomes:
// SELECT * FROM users WHERE email = '' OR '1'='1'
// → returns ALL users

Safe (parameterised query):

PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE email = ?");
stmt.setString(1, email);
// User input goes into the '?' slot as a typed string value
// It is NEVER parsed as SQL — injection is structurally impossible

Key vocabulary:

• Input binding — attaching user data to a parameter slot in the query template
• Query template — the SQL structure with ? placeholders, compiled separately from the data
• SQL structure separated from data — the core principle that makes injection impossible
• String concatenation / interpolation — the dangerous pattern that enables SQL injection

SAST = white-box, analyses code at rest. DAST = black-box, attacks a running application. Both are needed — they find different vulnerability types.

Key vocabulary: "false positive rate", "shift-left security", "security gate in CI", "SCA (Software Composition Analysis)" — scanning dependencies for known CVEs.

Path traversal = attacker uses ../../ sequences to escape the intended directory and reach arbitrary files on the server.

Example attack:

GET /download?file=../../../../etc/passwd
// If the application does: readFile('/uploads/' + filename)
// The resolved path becomes: /uploads/../../../../etc/passwd → /etc/passwd

Secure mitigation:

// Java example — canonicalise and validate the path stays within bounds
String basePath = "/var/app/uploads/";
File requested = new File(basePath + filename).getCanonicalFile();
if (!requested.getPath().startsWith(basePath)) {
    throw new SecurityException("Path traversal detected");
}

BOLA/IDOR = the endpoint fetches a resource by ID without verifying that the requester owns or is permitted to access it. The fix is an ownership/permission check — not opaque IDs.

Correct code review comment:

// Add ownership check before returning the resource:
const document = await db.documents.findById(id);
if (document.ownerId !== currentUser.id) {
    throw new ForbiddenError("Access denied");
}

Key vocabulary: "authorisation bypass", "insecure direct object reference", "horizontal privilege escalation", "ownership check", "object-level access control".

Shift-left = move security earlier in the development lifecycle. The cost of fixing a security issue grows dramatically the later it is caught.

When is a security backlog acceptable? Non-critical technical debt items (e.g., rotating a non-sensitive internal key, upgrading a library with no known exploit) may reasonably be deferred. Design-level vulnerabilities with active exploitation potential should not be deferred — they compound over time as more dependent code is built on the insecure foundation.

Key vocabulary: "SDLC security gates", "threat model review in design phase", "security champion", "DevSecOps", "shift-left security", "security technical debt".