Web application security (OWASP Top 10)

In short

Web application security is the practice of designing, building and testing web applications so that attackers cannot read, alter or destroy data or take over accounts through the application's own interfaces. The OWASP (Open Worldwide Application Security Project) Top 10 is a free, community-ranked list of the ten most critical web application risk categories; the current edition in wide use is OWASP Top 10 - 2021, with a 2025 revision released for community review (check owasp.org for the finalised edition before quoting it as current). It matters because almost every Indian bank, fintech, SaaS and government portal is a web or API application, and breaches invite liability under the Information Technology Act, 2000 (Sections 43A and 72A), the Digital Personal Data Protection Act, 2023 and CERT-In's 2022 directions on 6-hour incident reporting. It is examined in university "Information Security" and "Web Technology" papers, in GATE CS (security unit), and asked in almost every product-company, service-company and security-role interview (TCS, Infosys, Wipro, Accenture, Paytm, Razorpay, Zoho, Freshworks, banks' IT security teams).

Explained

What the OWASP Top 10 is and how it is built

• OWASP is a non-profit software security community; its material (Top 10, ASVS, Testing Guide, Cheat Sheets, ZAP tool) is free and vendor-neutral.
• The Top 10 is an awareness document, not a certification standard - it lists *risk categories*, each mapped to many CWEs (Common Weakness Enumeration IDs).
• Built from (a) data contributed on ~400+ CWEs across hundreds of thousands of applications and (b) a community survey for emerging risks not yet visible in data.
• Ranking factors: incidence rate (how often the weakness is found), exploitability, detectability and technical impact.
• Revised roughly every 3-4 years: 2010, 2013, 2017, 2021, next revision 2025. For audit-grade requirements use OWASP ASVS (Application Security Verification Standard, Levels 1-3) or OWASP SAMM; use the Top 10 for awareness and triage.

The ten categories (2021 edition), with mechanism and defence

1. A01 Broken Access Control - the application does not enforce *what a logged-in user is allowed to do*. Includes IDOR (insecure direct object reference: changing /invoice?id=101 to 102), vertical escalation (a normal user reaching /admin), forced browsing, missing function-level authorisation on APIs, and CORS misconfiguration. Defence: deny by default; enforce authorisation server-side on every request from the session identity, never from a client-supplied role/ID; use non-guessable or ownership-checked references; centralise checks in a filter/middleware; log failures.
2. A02 Cryptographic Failures (was "Sensitive Data Exposure") - data in transit or at rest unprotected or weakly protected: plain HTTP, old TLS, hardcoded keys, MD5/SHA-1 password hashing, ECB mode, weak random. Defence: TLS 1.2/1.3 everywhere with HSTS; bcrypt/scrypt/Argon2 with per-user salt for passwords; AES-GCM for data; CSPRNG for tokens; classify data and do not store what is not needed.
3. A03 Injection - untrusted input becomes part of a command or query: SQLi, NoSQL injection, OS command injection, LDAP injection, ORM injection, and XSS (merged into Injection in 2021). Defence: parameterised queries / prepared statements, ORM with bound parameters, allow-list input validation, output encoding appropriate to the context (HTML body, attribute, JS, URL), stored procedures without dynamic SQL, LIMIT on queries.
4. A04 Insecure Design (new in 2021) - the flaw is in the design, not the code: no rate limiting on OTP, business logic that lets a coupon be reused, password reset that trusts an email in a request, no segregation of tenants. Defence: threat modelling (STRIDE), secure design patterns, misuse/abuse-case stories, reference architectures, limits and quotas built into the design.
5. A05 Security Misconfiguration - default accounts and passwords, directory listing on, debug/stack traces shown, unnecessary features enabled, missing security headers, over-permissive cloud buckets, unpatched sample apps. XML External Entity (XXE) injection is folded here. Defence: hardened repeatable builds, configuration as code, minimal install, generic error pages, security headers, automated configuration scanning.
6. A06 Vulnerable and Outdated Components - using a library, framework, CMS plugin or server version with known CVEs (Struts, Log4Shell in log4j2, old jQuery, old WordPress plugins). Defence: inventory with SBOM (CycloneDX/SPDX), SCA scanning (OWASP Dependency-Check, npm audit), patch SLAs, remove unused dependencies, get components only from official sources.
7. A07 Identification and Authentication Failures - credential stuffing allowed, weak or default passwords, no MFA, session IDs in the URL, sessions not rotated after login, no logout/timeout, weak OTP, insecure password recovery. Defence: MFA, block known-breached passwords, rate-limit and progressively delay failed logins, server-side session store, regenerate the session ID on login and privilege change, Secure; HttpOnly; SameSite cookies.
8. A08 Software and Data Integrity Failures - trusting code or data whose integrity is not verified: insecure deserialization (Java/PHP/Python objects from untrusted input leading to remote code execution), unsigned auto-updates, compromised CI/CD pipeline, scripts pulled from an unverified CDN. Defence: avoid deserializing untrusted data or use data-only formats (JSON) with strict type checks; digital signatures on updates and artefacts; Subresource Integrity (SRI) for CDN scripts; protect the build pipeline.
9. A09 Security Logging and Monitoring Failures - attacks are not detected because logins, access-control failures and high-value transactions are not logged, logs stay local, or there is no alerting; also logging secrets or PII. Defence: log security-relevant events with user, time, source IP and outcome in a parseable format; ship to a central SIEM; alert and have an incident response plan; retain as required - CERT-In's April 2022 directions require Indian entities to keep ICT system logs for 180 days within India and report specified cyber incidents within 6 hours of noticing them, and to sync clocks to NIC/NPL NTP.
10. A10 Server-Side Request Forgery (SSRF) - the server fetches a URL supplied by the user, so the attacker reaches internal services (http://169.254.169.254/ cloud metadata, http://localhost:8080/admin, internal databases). Defence: allow-list destination hosts/ports/schemes, resolve and validate the IP (block private/loopback/link-local ranges), disable redirects, no raw responses back to the client, segment the network.

Movement from 2017 to 2021 - commonly asked

The classic three attacks in detail (exam favourites)

• SQL injection types: *in-band* (error-based, UNION-based), *blind boolean-based* (page differs on true/false), *blind time-based* (SLEEP(5)), *out-of-band* (data exfiltrated via DNS/HTTP). Impact: authentication bypass, data theft, data modification, sometimes OS command execution via xp_cmdshell/COPY TO PROGRAM.
• XSS types: Stored (persistent) - payload saved in the database and served to every viewer; Reflected - payload in the request echoed back in the response; DOM-based - vulnerability in client-side JS writing user data into innerHTML/eval with no server involvement. Impact: session cookie theft, keylogging, fake login forms, worm-like spread. Defences: context-aware output encoding, frameworks' auto-escaping (React JSX, Thymeleaf, Django templates - beware dangerouslySetInnerHTML, |safe), input sanitisation with a library (DOMPurify, OWASP Java HTML Sanitizer), Content-Security-Policy, HttpOnly cookies (limits theft, does not fix XSS).
• CSRF (Cross-Site Request Forgery): the victim's browser is tricked into sending an authenticated state-changing request (cookie attached automatically) to the target site. Defences: synchroniser token per session/form, double-submit cookie, SameSite=Lax/Strict cookies, re-authentication for sensitive actions, checking Origin/Referer, and using POST for state change. Note: CSRF is *not* a separate Top 10 2021 category (modern frameworks protect by default) - it sits under Broken Access Control.
• XSS vs CSRF: XSS executes attacker script in the victim's browser and can read responses; CSRF only *sends* a blind request and cannot read the response (same-origin policy), but needs no script injection.

Security headers, cookies and the browser security model

• Same-Origin Policy (SOP): scheme + host + port must match for script to read another document's data; CORS headers (Access-Control-Allow-Origin) deliberately relax it - never use * with credentials, and never reflect the Origin header blindly.
• Key headers: Strict-Transport-Security (force HTTPS), Content-Security-Policy (restrict script/style sources, blocks most XSS), X-Content-Type-Options: nosniff, X-Frame-Options/frame-ancestors (clickjacking), Referrer-Policy, Permissions-Policy. X-XSS-Protection is obsolete.
• Cookie flags: Secure (HTTPS only), HttpOnly (JS cannot read), SameSite (cross-site send policy), Domain/Path scope, short Max-Age.
• Session management: long random session ID from a CSPRNG, stored server-side (or a signed, short-lived JWT), regenerate on login, idle and absolute timeouts, invalidate server-side on logout. JWT pitfalls: alg: none, HS256/RS256 confusion, no expiry check, no revocation list, secrets in the token.

Secure SDLC, testing and Indian compliance

• Shift left: security requirements → threat model → secure coding standard → SAST (source scanning: SonarQube, Semgrep) → SCA (dependencies) → DAST (running app: OWASP ZAP, Burp Suite) → IAST/pen test → WAF + monitoring in production. Bug bounty / VDP for continuous coverage.
• WAF (ModSecurity with the OWASP Core Rule Set, or a cloud WAF) is compensating control, not a fix - it blocks known patterns and buys patching time.
• Testing references: OWASP Web Security Testing Guide (WSTG), OWASP ASVS for requirements, OWASP API Security Top 10 (separate list; API1 Broken Object Level Authorisation is the API twin of IDOR), CVSS v3.1/v4.0 for severity scoring, OWASP Juice Shop / WebGoat for practice labs.
• Indian law and practice: IT Act, 2000 - Section 43A (compensation for failure to protect sensitive personal data with reasonable security practices), Section 72A (disclosure in breach of a lawful contract), Section 66 (computer-related offences), Section 65B of the Indian Evidence law for electronic evidence; DPDP Act, 2023 - security safeguards and breach intimation duties for Data Fiduciaries (rules notified progressively - verify the current compliance dates); CERT-In Directions, 28 April 2022 - 6-hour incident reporting, 180-day log retention in India; RBI cyber security framework and IT governance directions for banks, NBFCs and payment operators, including VAPT before go-live and periodically; SEBI CSCRF for market intermediaries; UIDAI security requirements for Aadhaar-linked systems; IS/ISO/IEC 27001:2022 adopted by BIS as the ISMS standard, with ISO/IEC 27034 for application security.

Key points

• OWASP Top 10 - free, community-ranked list of the ten most critical web application risk categories; awareness tool, not a compliance standard.
• A01 Broken Access Control - #1 risk in 2021; enforce authorisation server-side on every request, deny by default.
• IDOR - changing an object identifier in a URL/body to reach another user's record; fix with ownership checks, not obscure IDs alone.
• A03 Injection - untrusted data interpreted as code or query; prepared statements are the primary fix for SQLi.
• XSS - stored, reflected and DOM-based; fix with context-aware output encoding plus CSP; merged into Injection in 2021.
• CSRF - forged authenticated state-changing request; fix with anti-CSRF tokens and SameSite cookies.
• A04 Insecure Design - new in 2021; fixed by threat modelling (STRIDE) and abuse cases, not by patching code.
• A05 Security Misconfiguration - defaults, debug output, missing headers, open buckets; now includes XXE.
• A06 Vulnerable Components - track with an SBOM and SCA scanning; Log4Shell is the textbook case.
• A07 Authentication Failures - add MFA, rate limiting, breached-password checks, session ID regeneration on login.
• A08 Integrity Failures - insecure deserialization, unsigned updates, CI/CD compromise; use signatures and SRI.
• A09 Logging and Monitoring Failures - log security events centrally and alert; CERT-In: 180-day logs in India, 6-hour incident reporting.
• A10 SSRF - server fetches a user-supplied URL; allow-list hosts and block private/link-local IP ranges including cloud metadata.
• Defence in depth - validate input (allow-list), encode output, least privilege DB accounts, HTTPS with HSTS, security headers, WAF.
• SAST vs DAST - SAST reads source without running it (early, more false positives); DAST attacks the running app (fewer false positives, finds runtime/config issues).
• ASVS - verifiable requirements at Levels 1-3 for audits and contracts; use where the Top 10 is too coarse.
• Legal exposure in India - IT Act Sections 43A/72A, DPDP Act 2023 safeguards, CERT-In directions, RBI/SEBI VAPT mandates.
• A WAF is a shield, not a patch - it reduces exposure while the code is fixed.

Formulas and examples

Example 1 - SQL injection authentication bypass and its fix. Vulnerable PHP-style query:

$sql = "SELECT * FROM users WHERE user='" . $_POST['u'] .
       "' AND pass='" . $_POST['p'] . "'";

Input u = admin' -- and any password gives:

SELECT * FROM users WHERE user='admin' --' AND pass='x'

Everything after -- is a comment, so the password check disappears and the attacker logs in as admin. Input u = x' OR '1'='1 returns all rows. Fixed with a prepared statement:

$stmt = $pdo->prepare(
  "SELECT id, pass_hash FROM users WHERE user = ?");
$stmt->execute([$_POST['u']]);
$row = $stmt->fetch();
if ($row && password_verify($_POST['p'], $row['pass_hash'])) { /* login */ }

The driver sends the query plan and the data separately, so admin' -- is treated as a literal username string. Note password_verify with a bcrypt hash - never MD5.

Example 2 - CVSS v3.1 for an unauthenticated SQL injection giving full data read. Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N → AV 0.85, AC 0.77, PR 0.85, UI 0.85.

• Exploitability = 8.22 × 0.85 × 0.77 × 0.85 × 0.85 ≈ 8.22 × 0.4729 ≈ 3.887
• ISS = 1 − (1−0.56)(1−0)(1−0) = 1 − 0.44 = 0.56; Impact = 6.42 × 0.56 = 3.595
• Base = roundup(min(3.887 + 3.595, 10)) = roundup(7.482) = 7.5 → High

If the same flaw also allowed modification and denial of service (C:H/I:H/A:H): ISS = 1 − 0.44³ = 1 − 0.0852 = 0.9148; Impact = 6.42 × 0.9148 = 5.873; Base = roundup(3.887 + 5.873 = 9.760) = 9.8 → Critical.

Example 3 - OWASP risk rating of an IDOR on an invoice endpoint. Likelihood factors (0-9): skill 3, motive 9 (data), opportunity 9, size 9 (anonymous internet) → threat agent avg = 7.5; ease of discovery 7, ease of exploit 5, awareness 9, intrusion detection 8 (not logged) → vulnerability avg = 7.25. Likelihood = (7.5 + 7.25)/2 = 7.375 → HIGH. Impact factors: loss of confidentiality 7, integrity 3, availability 1, accountability 7 → technical avg = 4.5; financial damage 5, reputation 7, non-compliance 7 (DPDP), privacy violation 9 → business avg = 7.0. Impact = (4.5 + 7.0)/2 = 5.75 → MEDIUM, so overall risk = High likelihood × Medium impact = High - fix before release.

Example 4 - why password hashing choice decides breach severity. A dump of 2,00,000 password hashes is stolen. Attacker rig: 10 billion (10¹⁰) MD5 guesses/second, but only 10,000 (10⁴) bcrypt(cost 12) guesses/second.

• An 8-character lowercase+digit password: C = 36, L = 8 → N = 36⁸ = 2.821 × 10¹². Entropy = 8 × log₂36 = 8 × 5.17 = 41.4 bits.
• MD5: average time = 2.821 × 10¹² / (2 × 10¹⁰) ≈ 141 seconds - the whole dump falls in minutes.
• bcrypt cost 12: 2.821 × 10¹² / (2 × 10⁴) ≈ 1.41 × 10⁸ s ≈ 4.5 years for *one* password, and per-user salts prevent any shared effort or rainbow tables.
• A 12-character password from 94 printable characters: N = 94¹² ≈ 4.76 × 10²³, entropy = 12 × 6.55 = 78.6 bits - infeasible either way.

Example 5 - SSRF reaching cloud metadata, and the allow-list fix. An image-preview feature calls GET /preview?url=<user URL> server-side. Attacker sends url=http://169.254.169.254/latest/meta-data/iam/security-credentials/; the server, running on a cloud VM, returns temporary IAM credentials, and the attacker then reads the storage bucket. Fix: accept only https, resolve the hostname, reject any address in 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 and ::1/fc00::/7, re-check after each redirect (or disable redirects), allow only the whitelisted CDN domains, and return a processed thumbnail rather than the raw response.

Where it is used

• Banking, fintech and payments: RBI-regulated banks, NBFCs and PA/PG operators (Razorpay, PayU, Paytm, PhonePe) run mandatory VAPT and secure-code reviews before every major release; UPI and net-banking portals are continuously tested.
• IT services and product engineering: TCS, Infosys, Wipro, HCLTech, Accenture, Cognizant, LTIMindtree staff large application-security practices; Zoho, Freshworks, Postman, Zeta and Browserstack run internal AppSec and bug-bounty programmes.
• Government and public digital infrastructure: CERT-In, NIC and STQC empanelled auditors security-audit state portals, DigiLocker-integrated services, GST and IRCTC-class systems before hosting approval.
• Job roles: application security engineer, VAPT/penetration tester, secure code reviewer, DevSecOps engineer, product security engineer, SOC analyst triaging WAF alerts; and every backend/full-stack developer, who is expected to know injection, access control and session handling.
• Certifications and hiring filters: CEH, OSCP, OSWE, eWPTX, CompTIA Security+, CISSP; Indian service companies also test OWASP knowledge in internal "secure coding" assessments before client onboarding.
• E-commerce and healthtech: coupon/pricing logic abuse, account takeover and PII exposure are the dominant real-world incidents; DPDP Act, 2023 obligations make PII-exposing bugs a legal as well as technical issue.

Interview questions

• Q: What is the OWASP Top 10 and is it a standard? A: A community-produced, data-backed awareness list of the ten most critical web application risk categories, refreshed every few years; it is not a certification standard - OWASP ASVS provides verifiable requirements for audits.
• Q: Why did Broken Access Control become the #1 risk in 2021? A: It was found in some form in about 94% of tested applications, because authorisation is business-specific and cannot be auto-fixed by a framework the way injection or CSRF largely has been.
• Q: What exactly makes a prepared statement safe against SQL injection? A: The SQL text is parsed and planned before the data is bound, so user input can only ever be a literal value and never new syntax; string concatenation lets input change the parsed query.
• Q: Where would a prepared statement not help? A: When the dynamic part is an identifier or structure - table name, column name, ORDER BY column or LIMIT - which cannot be bound; those must be validated against an allow-list.
• Q: Difference between stored, reflected and DOM-based XSS? A: Stored XSS is saved server-side and served to many users; reflected XSS is echoed from the current request; DOM-based XSS happens entirely in client-side JavaScript that writes untrusted data into the DOM.
• Q: Does HttpOnly fix XSS? A: No. It only stops JavaScript from reading the cookie; the injected script can still make authenticated requests from the victim's browser, so you must still fix the output encoding.
• Q: XSS vs CSRF - which is more powerful and why? A: XSS, because the attacker's script runs in the victim's origin and can read responses and bypass CSRF tokens; CSRF can only send a blind request and cannot read the reply.
• Q: How do you prevent CSRF in a stateless REST API using a bearer token? A: A token sent in an Authorization header is not attached automatically by the browser, so classic CSRF does not apply; if the token lives in a cookie, use SameSite=Strict/Lax plus a CSRF token or double-submit cookie.
• Q: What is IDOR and how do you test for it? A: Access to an object by supplying its identifier without an ownership check; test by logging in as user A, capturing a request, replaying it with user B's session or with another object's ID, and confirming data is returned.
• Q: What is SSRF and why is cloud metadata the classic target? A: The server fetches an attacker-controlled URL; the link-local metadata endpoint 169.254.169.254 is reachable only from inside the instance and can return IAM credentials, so the SSRF converts into full cloud account access.
• Q: Which Top 10 item would an unpatched Log4j fall under? A: A06 Vulnerable and Outdated Components, with the exploitation itself being injection (JNDI lookup) - the control is dependency inventory with an SBOM plus patch SLAs.
• Q: SAST vs DAST vs SCA - when do you use each? A: SAST scans source code in the IDE/CI (earliest, noisier); SCA checks third-party dependencies against CVE databases; DAST attacks the running application in staging and catches configuration and runtime flaws that source scanning misses.
• Q: What are an Indian company's legal duties after a web application breach exposing customer data? A: Report the specified incident to CERT-In within 6 hours of noticing it and preserve 180 days of logs in India per the 2022 directions, meet DPDP Act, 2023 breach-intimation and safeguard duties (from 13 May 2027), and face possible compensation liability under Section 43A of the IT Act, 2000.

Common mistakes

• Writing that "the Top 10 lists ten vulnerabilities" - they are risk *categories* each covering many CWEs, and the list is not exhaustive or a compliance checklist.
• Quoting the 2017 list (XSS, XXE and insecure deserialization as separate items) as current - they were merged in 2021; also quoting a 2025 list as final without checking.
• Claiming client-side JavaScript validation or hidden fields provide security - anything checked only in the browser can be bypassed with a proxy; validation must be repeated server-side.
• Treating encoding, escaping, hashing and encryption as interchangeable, or using MD5/SHA-256 alone for passwords instead of bcrypt/Argon2 with a salt.
• Blocking keywords like SELECT or <script> with a blacklist and calling injection fixed; attackers encode, case-vary and nest payloads - use parameterisation and allow-lists.
• Confusing authentication with authorisation, and so fixing a login bug when the real flaw is a missing per-object ownership check.
• Assuming HTTPS, a WAF or a framework makes an application secure - they do not touch access-control and business-logic flaws, which are the most common and most costly.

Related topics

Cryptography basics · Identity and access management · Ethical hacking and penetration testing · Network security: firewalls, VPN and IDS · Security operations: SOC and SIEM · IT governance, risk and compliance