Application Security, Interview Questions.

A widely used awareness list of the most critical web application risk categories, maintained by OWASP. The 2021 edition includes broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, logging and monitoring failures, and SSRF. A newer edition may exist, so check the current list.

Untrusted input changes the meaning of a database query because it is concatenated into SQL. Prevent with parameterised queries (prepared statements), ORM use done safely, input validation as a second layer, least-privilege database accounts, and no detailed error messages to users.

# unsafe: query built from user text
# cur.execute("SELECT * FROM users WHERE name = '" + name + "'")

# safe: the driver sends the value separately from the SQL
cur.execute("SELECT * FROM users WHERE name = %s", (name,))

Attacker-controlled script runs in another user's browser in the site's origin. Stored XSS is saved on the server, reflected comes back in a response, and DOM-based happens in client-side code. Prevent with context-aware output encoding, a strong Content Security Policy, avoiding dangerous sinks like innerHTML, and HttpOnly cookies to limit damage.

Cross-site request forgery tricks a logged-in user's browser into sending an unwanted request. Prevent with anti-CSRF tokens, SameSite cookies, checking the Origin header, and requiring re-authentication for sensitive actions.

Authentication verifies identity. Authorisation checks what that identity may do. Broken access control, the top OWASP category, usually means the second step is missing or inconsistent, for example changing an ID in a URL to view someone else's data (IDOR).

Never store plain text or fast hashes. Use a slow, salted password hashing algorithm such as Argon2id, scrypt or bcrypt with proper cost, add breach checks, rate limit attempts, and offer MFA. Peppers kept outside the database add defence in depth.

Strict-Transport-Security forces HTTPS, Content-Security-Policy limits script sources, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, and framing control via CSP frame-ancestors. Cookies should be Secure, HttpOnly and SameSite.

Insecure direct object reference: the app exposes an identifier and fails to check ownership. Fix by enforcing authorisation on the server for every object access, derived from the session, not from a client-supplied value. Unpredictable IDs help but are not a fix.

Server-side request forgery makes the server fetch an attacker-chosen URL. In cloud environments it can reach the metadata service and internal systems. Defend with allowlists of destinations, blocking internal ranges after DNS resolution, disabling redirects, IMDSv2, egress filtering, and running with minimal credentials.

Common issues: accepting the none algorithm or algorithm confusion, weak secrets, missing expiry or audience checks, storing tokens where scripts can read them, and no revocation plan. Pin algorithms, validate all claims, keep lifetimes short, and use refresh rotation.

• SAST analyses source code without running it.
• DAST tests a running app from outside.
• IAST instruments the app during tests.
• SCA inventories dependencies and flags known vulnerable versions and licence issues.

Use them together and tune results, since each has false positives and blind spots.

A structured way to find design-level risks before code exists. Draw a data flow diagram, mark trust boundaries, apply STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) to each element, rank risks, and decide mitigations. Update it as the design changes.

Security activities across the lifecycle: requirements and abuse cases, design review and threat modelling, secure coding standards and training, SAST and SCA in CI, code review, DAST and testing before release, secrets scanning, and monitoring and incident response in production. Automate checks and keep them fast to avoid friction.

Maintain an inventory (SBOM), run SCA in CI and on a schedule, prioritise reachable and exploited issues (use EPSS and the KEV list), update regularly with automated pull requests, pin and verify packages, and avoid abandoned libraries. Log4Shell-type events show how fast you must be able to find usage.

Broken object level and function level authorisation, excessive data exposure, missing rate limits, mass assignment, weak authentication, improper inventory (shadow or old versions) and unsafe consumption of third-party APIs. The OWASP API Security Top 10 covers them.

CORS relaxes the same-origin policy for chosen origins. Mistakes: reflecting any Origin, allowing credentials with a wildcard-like policy, trusting null, and thinking CORS protects the server (it only governs browsers). Use explicit allowlists.

Check type by content not just extension, limit size, store outside the web root with random names, serve from a separate domain with a safe content type, scan for malware, strip metadata, and never execute uploaded content.

Valid requests used in invalid ways: skipping a payment step, reusing coupons, race conditions on balances, negative quantities. Scanners miss them. Find with threat modelling, abuse-case tests, state-machine review and concurrency testing. Fix with server-side workflow enforcement and atomic transactions.

Deserialising untrusted data into objects can trigger unexpected code paths. Avoid native object serialisation for untrusted input, use simple data formats with strict schemas, restrict allowed types, sign data, and keep libraries updated.

Use an established identity provider and OAuth 2.0 authorisation code flow with PKCE, short-lived access tokens, rotating refresh tokens, tokens kept out of script-readable storage where possible (backend-for-frontend with secure cookies is a strong pattern), strict redirect URI matching, MFA, and server-side authorisation on every API call.

Two requests interact with shared state in an unsafe order, such as redeeming one voucher twice by sending requests at the same moment. Fix with database transactions and row locks or unique constraints, idempotency keys, and atomic updates.

-- atomic: only one request can flip the voucher from unused to used
UPDATE vouchers SET used = true WHERE id = 42 AND used = false;
-- check affected rows = 1 before granting the benefit

Embed security champions in teams, give paved-road templates and libraries, automate checks in CI with fast feedback, risk-tier applications, define SLAs for fixes, measure mean time to remediate and recurring vulnerability classes, and run training from real findings. Success means fewer classes of bugs, not just more findings.

Start in report-only mode, define allowed sources per directive, avoid unsafe-inline by using nonces or hashes, use strict-dynamic carefully, set frame-ancestors and base-uri, and monitor reports. A good CSP greatly reduces XSS impact.

Prompt injection (direct and via retrieved content), data leakage, insecure output handling when model output feeds other systems, excessive agency from tool access, poisoned training or retrieval data, and cost abuse. Treat model output as untrusted input, scope tool permissions tightly, require human approval for risky actions, and log prompts and tool calls.

Reproduce, assess data exposed and exploit ease, check logs for abuse, fix with ownership checks in the shared data layer (not just that endpoint), add automated authorisation tests, and review sibling endpoints for the same pattern.

Use the SBOM or dependency graph to find affected services, check exposure and exploitation reports, apply vendor patch or a temporary mitigation (WAF rule, config), prioritise internet-facing systems, monitor for exploitation attempts, and verify fixes. Afterwards, improve inventory speed.

Measure where the delay is, shift checks left into automated tooling, provide secure defaults and libraries, tier reviews by risk so low-risk changes skip manual review, and offer office hours. Position security as enabling speed with fewer incidents.

Revoke and rotate first, check logs for use, purge from history, move secrets to a vault, add pre-commit and CI secret scanning, and review how it got there. Rotation matters more than deleting the commit.