OWASP Top 10 Explained: Web App Security Risks for India

What the OWASP Top 10 Is

The Open Worldwide Application Security Project (OWASP, formerly Open Web Application Security Project) is a community-driven non-profit that publishes free guidance on application security. The OWASP Top 10 is its flagship publication: a list of the most critical web application security risks, updated approximately every 3 to 4 years based on contributor data, CVE trends, and community input.

The current Top 10 is the 2021 edition. A 2025 / 2026 revision is in community review but the 2021 categories remain the reference in customer security questionnaires, regulator documents and audit checklists through 2026. The categories cover broad risk classes rather than specific vulnerabilities; a single OWASP category often covers dozens or hundreds of specific CWE entries.

Codesecure web application pentest reports map every finding to the relevant OWASP Top 10 category plus the underlying CWE. Customers use this mapping in audit evidence, customer questionnaire responses, and internal severity reporting.

A01 to A05: Access, Crypto, Injection, Design, Config

A01 Broken Access Control. Definition: failures in authorisation that allow users to act outside their intended permissions. Example: substituting another user's ID in a URL (/api/users/123 to /api/users/456) and seeing their data. Fix: enforce server-side authorisation on every request, default deny, role-based or attribute-based access control with explicit checks at every sensitive operation. Found in 94 percent of applications tested in OWASP's dataset; consistently the most prevalent category.

A02 Cryptographic Failures. Definition: missing or incorrect use of cryptography that exposes sensitive data. Example: passwords stored in plaintext or weakly hashed (MD5, SHA-1 without salt), TLS not enforced on sensitive endpoints, hardcoded encryption keys. Fix: use modern algorithms (Argon2id or bcrypt for passwords, AES-256-GCM for data at rest, TLS 1.3 in transit), proper key management (KMS, Key Vault, Secret Manager), encrypted backups and transit channels.

A03 Injection. Definition: untrusted data treated as code by an interpreter. SQL injection is the classic; NoSQL injection, OS command injection, LDAP injection, expression-language injection and template injection are all in scope. Example: user input concatenated into a SQL query allowing attacker to extract or modify the database. Fix: parameterised queries (never string concatenation), input validation (allowlist where possible), output encoding, least-privilege database accounts, prepared statements at the ORM layer.

A04 Insecure Design. Definition: missing or ineffective security control design (not implementation flaws but design flaws). Example: a password-reset flow that emails the actual password (design flaw), a financial transaction without secondary verification (design flaw). Fix: threat modelling early in design, secure design patterns (assume breach, defence in depth), reference architectures, security requirements alongside functional requirements.

A05 Security Misconfiguration. Definition: insecure default configurations, incomplete or ad hoc configurations, unnecessary features enabled. Example: cloud storage left publicly readable, application debug mode enabled in production, default credentials retained on admin interfaces. Fix: hardening baselines (CIS Benchmarks), infrastructure as code with policy enforcement, configuration management, periodic config review.

A06 to A10: Components, Auth, SSRF, Logging, Software

A06 Vulnerable and Outdated Components. Definition: use of components (libraries, frameworks, OS packages, runtimes) with known vulnerabilities or that are unsupported. Example: a Log4j-vulnerable JAR retained after Log4Shell, an outdated Spring framework version. Fix: software composition analysis (Dependabot, Renovate, Snyk Open Source, OSSF Scorecard), pinned dependency versions, vulnerability tracking with remediation SLAs, decommissioning of abandoned components.

A07 Identification and Authentication Failures. Definition: confirmation of user identity that can be bypassed, brute-forced, or session-fixated. Example: missing MFA on critical accounts, predictable session IDs, password reset tokens that do not expire, weak password policies. Fix: enforce MFA (preferably FIDO2 / WebAuthn / passkeys for phishing resistance), strong session management with secure cookie flags, rate-limited authentication endpoints, password complexity aligned with NIST SP 800-63 (length over complexity).

A08 Software and Data Integrity Failures. Definition: failure to verify integrity of software updates, critical data or CI/CD pipelines. Example: auto-updates without signature verification, deserialisation of untrusted data, CI/CD pipeline that pulls unverified dependencies. Fix: digital signatures on updates and packages (cosign for containers, GPG for packages), supply-chain integrity tooling (SLSA, Sigstore), strict CI/CD access controls, integrity verification before execution.

A09 Security Logging and Monitoring Failures. Definition: insufficient logging, missing monitoring, slow incident response due to lack of visibility. Example: authentication failures not logged, suspicious activity not alerted, log integrity not protected. Fix: structured logging for security events, central log aggregation in SIEM, detection content for relevant attacker techniques, integration with the SOC for response.

A10 Server-Side Request Forgery (SSRF). Definition: server-side functionality fetches a URL based on user input without sufficient validation, allowing attacker-controlled requests from the server's network position. Example: webhook configuration that lets attacker target internal services or cloud metadata endpoints. Fix: validate and allowlist URLs before fetching, network-layer egress controls preventing access to internal subnets or metadata endpoints, IMDSv2 enforcement on AWS, header validation on Azure / GCP metadata.

OWASP Top 10 in Indian Regulatory Context

PCI DSS 4.0 references OWASP Top 10 directly for application security testing. Web applications handling cardholder data must address OWASP Top 10 categories with documented mitigations.

RBI Cyber Security Framework references secure development practices and VAPT; OWASP Top 10 coverage is the de facto methodology for application VAPT.

SEBI Cyber Security and Cyber Resilience Framework similar approach; regulated entities are expected to test against OWASP-aligned methodology.

IRDAI Information and Cyber Security Guidelines similar.

DPDP Act 2023 Section 8 reasonable security safeguards is broadly interpreted to include addressing OWASP Top 10 risks for any application processing personal data. Audit and inspection events typically reference OWASP coverage as part of evidence review.

Fixing OWASP Findings Sustainably

Pentest finds OWASP Top 10 issues reactively. Fixing them requires both immediate remediation and process changes that prevent reintroduction. The sustainable pattern includes: secure coding training for developers, security requirements alongside functional requirements at design time, automated security testing in CI (SAST, DAST, SCA, secret scanning, IaC scanning), security review at PR time for sensitive changes, periodic threat modelling for new features, pre-deployment validation including DAST and pentest for major releases, and continuous VAPT for production-critical applications.

The combination of reactive (pentest) and proactive (secure SDLC) is what closes OWASP risks sustainably. Either alone leaves gaps. Codesecure delivers integrated programmes that include both pentest and SDLC consulting for Indian product teams.

Common SDLC tooling: SAST (SonarQube, Semgrep, Snyk Code, Checkmarx, GitHub Advanced Security CodeQL), DAST (OWASP ZAP, Burp Suite Enterprise, Acunetix, Invicti), SCA (Snyk Open Source, Dependabot, OSSF Scorecard), secret scanning (GitLeaks, TruffleHog, GitHub Secret Scanning), IaC scanning (Checkov, tfsec, KICS), and security training (PortSwigger Web Security Academy free, Secure Code Warrior, Hack The Box, Pluralsight). Codesecure helps clients select and integrate.

How Pentest Engagements Map to OWASP Top 10

A standard Codesecure web application pentest covers every OWASP Top 10 category systematically, with depth determined by the application's specific risk profile. Each finding in the report is mapped to: the OWASP Top 10 category, the specific CWE (Common Weakness Enumeration) entry, CVSS v3.1 base and environmental score, suggested CVSS environmental modifiers for the customer's context, compliance framework mapping (ISO 27001, SOC 2, PCI DSS, RBI, DPDP), and concrete remediation guidance.

Customers use this mapping in multiple downstream contexts: ISO 27001 internal audit evidence, SOC 2 control evidence, PCI DSS Requirement 6 evidence, RBI inspection, customer security questionnaire responses, internal risk reporting, and engineering team prioritisation. The cross-mapping is what makes the pentest report useful beyond the immediate remediation cycle.

Where OWASP Top 10 Is Going

The community is working on the 2025 / 2026 OWASP Top 10 revision. Expected changes (subject to community finalisation) include: continued prominence of access control and injection, increased weight on supply-chain integrity and identity attacks, possible new category around API-specific risks (which currently live in the separate OWASP API Security Top 10), AI / LLM-specific risks possibly added or referenced (currently the OWASP LLM Top 10 is the separate authoritative reference).

Codesecure tracks the revision and updates engagement methodology when the new edition publishes. For now, the 2021 edition is the reference in audits, customer questionnaires and regulator interpretation. Our companion OWASP LLM Top 10 blog covers the AI-specific risk picture in parallel.