Web Application Security Guide: Risks, Controls, Testing

Web applications are the most exposed software most organisations run, and exploiting a public-facing application remains one of the most direct routes into a network. This guide is the overview page for web application security on this site: what the discipline covers, how the main reference lists (OWASP Top 10:2025, CWE Top 25, OWASP ASVS 5.0) fit together, which controls matter across the build and run lifecycle, and how to test, monitor and measure a programme. It is written for application security leads, engineering managers and security architects who need one map of the field before going deep. Each section summarises a topic and links the detailed guide rather than repeating it.

Key takeaways

Access control is the top risk, not injection. OWASP Top 10:2025 ranks Broken Access Control first, and Missing Authorization (CWE-862) sits fourth in the 2025 CWE Top 25: authorisation checks have to live on the server, for every object and every function.
Use ASVS as the requirement set, the Top 10 as the awareness list. The Top 10 explains the most common risk categories; ASVS 5.0 turns them into verifiable requirements across 17 chapters, at three levels.
Security belongs in the lifecycle, not at the end. NIST SP 800-218 (SSDF) and OWASP SAMM give the process frame: requirements, threat modelling, secure build, testing and vulnerability response.
Sessions and tokens are identity assets. Session cookies, JWTs, API keys and the application's own service credentials are what attackers steal after the first foothold; treat them with the same discipline as passwords.
A WAF buys time, it does not fix code. Runtime protection, logging and alerting reduce dwell time, but the measure of success is fewer exploitable defects shipped and faster remediation of the ones that are found.

What web application security covers

Web application security is the set of design, coding, configuration, testing and operational practices that keep browser-facing applications and the APIs behind them from being misused. It spans four layers, and a programme that covers only one of them leaves predictable gaps:

Code and design: input handling, output encoding, authorisation logic, business logic and the safe use of frameworks. Most high-impact defects start here.
Components: open source libraries, frameworks, container images and build tooling. OWASP moved Software Supply Chain Failures to third place in the 2025 list. See the SBOM Guide.
Configuration and platform: TLS, HTTP security headers, cookie attributes, error handling, cloud metadata access and default accounts. Security Misconfiguration is second in the 2025 list.
Runtime and operations: WAF and bot controls, logging, alerting, incident response and patching. ATT&CK tracks exploitation of web-facing systems as T1190 Exploit Public-Facing Application, and post-exploitation persistence often takes the form of T1505.003 Web Shell.

APIs are part of the same attack surface and share most controls, with their own failure modes (object-level authorisation, excessive data exposure, unsafe consumption of third-party APIs). See the API Security Guide.

The risk landscape: OWASP Top 10:2025 and CWE Top 25

Two lists anchor most programmes. The OWASP Top 10 is a risk-awareness document built from contributed data and a community survey; the CWE Top 25 ranks weakness types by how often and how severely they appear in published CVE records. They answer different questions and work best together.

OWASP Top 10:2025 category	What it looks like in practice	Primary control
A01 Broken Access Control	IDOR, missing checks on PUT/DELETE endpoints, JWT or cookie tampering, CORS misconfiguration, force browsing	Deny by default, server-side checks reused from one mechanism, record ownership tests
A02 Security Misconfiguration	Verbose errors, default accounts, open cloud storage, missing headers, directory listing	Hardened build images, configuration as code, automated drift checks
A03 Software Supply Chain Failures	Vulnerable or malicious dependencies, compromised build pipeline	SCA, SBOM, pinned and verified dependencies, pipeline hardening
A04 Cryptographic Failures	Plaintext transport, weak hashing of passwords, hard-coded keys	TLS everywhere with HSTS, modern password hashing, managed keys
A05 Injection	SQL, NoSQL, OS command, LDAP injection and XSS	Parameterised queries, contextual output encoding, safe APIs
A06 Insecure Design	Missing rate limits on business flows, flawed trust assumptions	Threat modelling and abuse cases at design time
A07 Authentication Failures	Credential stuffing, weak recovery flows, session fixation	MFA or passkeys, rate limiting, session ID regeneration
A08 Software or Data Integrity Failures	Unsigned updates, insecure deserialisation, untrusted CDN scripts	Signature verification, integrity checks, safe deserialisation
A09 Security Logging and Alerting Failures	Attacks that leave no trace or raise no alert	Security event logging with alerting and tested response
A10 Mishandling of Exceptional Conditions	Fail-open error paths, leaked stack traces, unhandled edge cases	Fail closed, centralised error handling, negative testing

The 2025 CWE Top 25 puts web weaknesses at the head of the list: CWE-79 Cross-site Scripting first, CWE-89 SQL Injection second, CWE-352 Cross-Site Request Forgery third and CWE-862 Missing Authorization fourth, with CWE-22 Path Traversal, CWE-78 OS Command Injection and CWE-94 Code Injection also in the top ten. Use the CWE IDs to tag findings from scanners and tests so you can trend weakness classes over time. See the OWASP Top 10 Guide, the CWE Top 25 Guide and, for attack mechanics, the Web Application Attacks Guide.

Security across the development lifecycle

Defects are cheapest to remove before they ship. Two process frameworks are widely used, and they complement rather than compete:

Framework	Structure	Best used for
NIST SP 800-218 SSDF v1.1 (final, February 2022)	Practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV)	An outcome-based baseline that buyers and regulators recognise; it underpins the CISA secure software attestation form
OWASP SAMM v2	Five business functions (Governance, Design, Implementation, Verification, Operations), each with three practices such as Threat Assessment, Secure Build and Security Testing	Measuring maturity and building a staged improvement roadmap
OWASP ASVS 5.0	17 chapters of verifiable requirements at levels 1 to 3	Writing security requirements and acceptance criteria per application

In practice: adopt ASVS as the requirement catalogue, threat model new features and significant changes, give each team a security champion, and gate releases on agreed severity thresholds rather than on zero findings. CISA's Secure by Design pledge goals (MFA, removing default passwords, reducing entire classes of vulnerability, security patches, a vulnerability disclosure policy, CVE reporting and evidence of intrusions) are a useful outside check for vendors that ship web software to customers. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide, the Threat Modelling Guide, the DevSecOps Guide and the Security Champions Programme Guide.

Core control areas

ASVS 5.0 chapters are a practical way to organise controls. The table maps the chapters most relevant to a typical web application to the concrete decisions behind them.

ASVS 5.0 chapter	Key decisions	Detailed guide
V1 Encoding and Sanitization	Parameterised queries, contextual output encoding, canonicalise input once before validation	SQL Injection Prevention Guide
V3 Web Frontend Security	CSP, HSTS, cookie attributes, framing controls, CORS policy	Security Headers Guide
V4 API and Web Service	Schema validation, method restrictions, GraphQL limits	OpenAPI Specification Security Guide
V5 File Handling	Type and size checks, storage outside the web root, malware scanning	File Upload Security Guide
V6 Authentication, V7 Session Management	MFA or passkeys, recovery flows, session lifetime and revocation	MFA Guide
V8 Authorization	Object, function and field-level checks enforced server-side	OWASP API Top 10 API1 Broken Object Level Authorization Guide
V9 Self-contained Tokens, V10 OAuth and OIDC	Signature and audience validation, algorithm allow-lists, PKCE	JWT and Session Tokens in Code and Logs Guide
V13 Configuration, V16 Logging and Error Handling	Secrets out of code, no debug in production, security event logs	Web Application Hardening Checklist

Baseline settings worth checking first

Transport: HTTPS only, with Strict-Transport-Security: max-age=63072000; includeSubDomains. Preloading needs a max-age of at least 31536000 and includeSubDomains, and is hard to undo, so add preload only once every subdomain serves HTTPS. ASVS V3.4.1 requires the header on all responses.
Session cookies: Secure, HttpOnly, an explicit SameSite=Strict or Lax, and the __Host- prefix (which requires Secure, Path=/ and no Domain attribute). The OWASP Session Management Cheat Sheet asks for at least 64 bits of entropy from a CSPRNG and a new session ID after login or any privilege change. See the Cookie Security Guide.
Timeouts: server-enforced idle and absolute timeouts; OWASP cites 2 to 5 minutes idle for high-value applications and 15 to 30 for low-risk ones. Invalidate the session on the server at logout.
Browser-side injection: a nonce- or hash-based Content Security Policy, deployed first in report-only mode. See the Content Security Policy Guide and the Cross-Site Scripting (XSS) Prevention Guide.
State-changing requests: anti-CSRF tokens or framework protection; SameSite is defence in depth, not a replacement. See the CSRF Prevention Guide.
Outbound requests: allow-list destinations for any server-side URL fetch and block cloud metadata endpoints. The Capital One breach showed how SSRF turns into stolen cloud role credentials. See the SSRF Prevention Guide.

Where identity fits

Most serious web compromises end in an identity outcome: a stolen session, a forged token, or the application's own credentials used to reach data stores and cloud APIs. Three identity questions belong in every application review:

User sessions: a session cookie is a bearer credential that bypasses MFA once issued (ATT&CK T1539 Steal Web Session Cookie). Short lifetimes, server-side revocation and, where supported, device binding limit the damage. See the Device-Bound Session Credentials (DBSC) Guide.
Application credentials: database passwords, API keys and cloud keys used by the application are non-human identities. Keep them in a secrets manager, scope them to least privilege and rotate them; never ship them in front-end code or repositories.
Service-to-service trust: prefer workload identity (managed identities, OIDC federation) over static keys, so a compromised web tier cannot reuse long-lived credentials elsewhere. See the Zero Trust Identity Guide.

Testing and verification

No single test type finds everything. Combine them by what each is good at, and tag every finding with a CWE ID.

Technique	Finds well	Misses	When to run
SAST	Injection sinks, dangerous APIs, hard-coded secrets	Authorisation and business logic, runtime configuration	Every pull request, incremental
SCA and SBOM	Known-vulnerable and licence-risk components	Defects in your own code	Every build, plus continuous monitoring of deployed SBOMs
DAST	Missing headers, reflected injection, misconfiguration	Deep authenticated flows, multi-step logic	Nightly against staging, authenticated
Manual penetration test	Access control, chained flaws, business logic	Breadth across many releases	Before major releases and at least annually for critical apps
Bug bounty or VDP	Real-world creative findings	Systematic coverage	Once triage capacity exists

Decision guidance: a small organisation with a few applications gets most value from a framework with secure defaults, SCA, a DAST baseline and an annual test against ASVS Level 2. A large portfolio needs tiering: Level 3 and manual testing for applications handling payments, health or identity data, automated coverage for the long tail, and a central team that owns tooling while product teams own fixes. The OWASP Web Security Testing Guide (stable release v4.2, with v5.0 in development) gives test case IDs in the WSTG-<category>-<number> format to reference in test plans. See the Web Application Security Testing Guide and the Bug Bounty and Vulnerability Disclosure Guide.

Runtime protection, detection and measurement

A web application firewall with a managed rule set and virtual patching blocks commodity attacks and covers the gap between disclosure and fix. For organisations handling card data, PCI DSS v4.0 requirement 6.4.2 calls for an automated technical solution in front of public-facing web applications; see the Web Application Firewall Guide. Automated abuse such as credential stuffing and scraping needs its own controls; see the Bot Management Guide.

What to log: authentication success and failure, MFA events, session creation and revocation, authorisation failures (OWASP recommends alerting on repeated access control failures), input validation rejections, administrative actions and changes to security settings. Send them to the SIEM with user, session and request identifiers but never with the session token or password itself.

Metrics that show it is working:

Mean time to remediate critical and high findings, by application tier, against an agreed SLA.
Escape rate: share of findings first discovered in production (pen test, bounty, incident) rather than in the pipeline.
Weakness recurrence: new findings per CWE class per quarter; a class that keeps returning needs a framework or library fix, not more training.
Coverage: percentage of internet-facing applications with an owner, SBOM, authenticated DAST and a test in the last 12 months.
Header and cookie compliance: share of production hosts passing an automated HSTS, CSP and cookie attribute check.

Implementation roadmap

Inventory: list every internet-facing application and API with an owner, data classification and technology stack. Unknown applications are the usual entry point.
Baseline: enforce HTTPS and HSTS, cookie attributes and removal of default accounts and debug endpoints; put a WAF in detection mode in front of critical applications.
Pipeline: add SCA and secret scanning to every build, then SAST on pull requests, with findings routed to the owning team. Start in report-only mode for two to four sprints to tune noise.
Requirements: adopt ASVS Level 2 as the default acceptance criteria and threat model new features. See the Application Security Requirements from ASVS.
Enforce: move the WAF to blocking for tuned rules, deploy CSP from report-only to enforcing, and gate releases on critical findings.
Verify: run authenticated DAST and risk-based manual testing; open a vulnerability disclosure channel.
Roll back safely: keep header, CSP and WAF changes behind configuration flags so a breaking policy can be reverted in minutes without a code release, and record every rollback as a defect to fix.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	PR.PS-06; ID.RA-01; DE.CM-09	Secure development integrated in the SDLC; vulnerabilities identified and recorded; runtime monitoring
NIST SP 800-53 Rev. 5	SA-8, SA-11, SA-15, SI-10, SC-8, SC-23, AC-3, AU-12, RA-5, SI-2	Engineering principles, developer testing, input validation, transport, session authenticity, access enforcement, logging, scanning, remediation
ISO/IEC 27001:2022 Annex A	8.25 Secure development life cycle; 8.26 Application security requirements; 8.28 Secure coding; 8.29 Security testing in development and acceptance	Organisational controls for building and testing applications
CIS Controls v8.1	Control 16 Application Software Security	Secure development process, third-party component management, testing
MITRE ATT&CK v20	T1190; T1505.003; T1539	Initial access through web apps, web shell persistence, session cookie theft
MITRE CAPEC	CAPEC-66 SQL Injection; CAPEC-63 Cross-Site Scripting (XSS)	Attack patterns for test design

Common failure patterns

Authorisation enforced in the front end. Hiding a button is not access control; the API behind it must check every object and function on the server.
Unauthenticated endpoints nobody inventoried. The McKinsey AI platform hack began with SQL injection in unauthenticated APIs that an automated agent found quickly; attackers enumerate faster than annual tests.
Treating the WAF as the fix. Virtual patches stay in place for years while the vulnerable code is never changed, and bypasses through direct origin access go unnoticed.
Server-side fetches without egress control. SSRF to a metadata service hands out cloud credentials, as in the Capital One breach.
Scanner noise without ownership. Thousands of untriaged findings with no owning team; real criticals get lost and engineers stop reading reports.
Long-lived sessions and credentials. Sessions that never expire and application keys that never rotate turn any token leak into lasting access.

Practitioner checklist

Maintain an inventory of internet-facing applications and APIs with named owners and data classification.
Adopt OWASP ASVS 5.0 Level 2 as default requirements, Level 3 for high-risk applications.
Enforce server-side, deny-by-default authorisation and test it with per-role and per-object test cases.
Set HSTS, a nonce-based CSP and Secure, HttpOnly, SameSite cookies with the __Host- prefix.
Run SCA and secret scanning on every build and keep an SBOM for every deployed release.
Combine SAST, authenticated DAST and risk-based manual testing, tagging findings by CWE.
Move application credentials into a secrets manager or workload identity and rotate them.
Log authentication, session and authorisation events to the SIEM and alert on repeated failures.
Track remediation time, escape rate and weakness recurrence by application tier.

Where to go next

Attacks and weaknesses: Web Application Attacks Guide (attack classes and defences), Lesser-Known Web Flaws (less familiar bug classes), Insecure Deserialisation Guide, NoSQL Injection Prevention Guide, Clickjacking Guide and CORS Misconfiguration Guide.
Hardening: Web Application Hardening Checklist (configuration baseline) and Security Headers Guide (header-by-header settings).
Testing: Web Application Security Testing Guide (methods and tooling) and API Penetration Testing Guide.
Runtime protection: Web Application Firewall Guide (deployment, tuning and PCI DSS 6.4.2) and Bot Management Guide.
Secure development: DevSecOps Guide, AI-Assisted Code Review and AI SAST Guide and Software Liability and Secure by Design Policy Guide.

Standards and references

Related NHI Mgmt Group resources: API Security Guide · OWASP Top 10 Guide · Web Application Attacks Guide · Web Application Firewall Guide · Zero Trust Identity Guide

Web Application Security Guide