Practical definition
A web application vulnerability is a weakness that lets a user or system cross an intended security boundary. A useful finding proves the reachable condition, explains the resulting impact, records the affected scope, and gives the team a testable path to remediation.
A scanner alert is not automatically a vulnerability, and a vulnerability name is not a severity rating. “Cross-site scripting” can mean a self-contained alert box in an isolated admin preview or a reliable route to privileged session actions. The label is the start of analysis, not the end.
The current OWASP Top 10:2025 ranks categories of application risk rather than individual findings. Broken Access Control remains first. Security Misconfiguration moved to second, Software Supply Chain Failures is third, and Injection is fifth. Use the list to organize coverage, not as a substitute for a threat model or a finding-specific severity assessment.
Run them against an application you own, a dedicated test environment, or a lab where you have written permission. Use synthetic records and stop after the minimum evidence needed to prove impact.
Common web application vulnerabilities: quick reference
The severity ranges below are illustrative, not automatic scores. The same flaw can move several levels when authentication, data sensitivity, privileges, or blast radius changes.
| Vulnerability | Typical proof | Possible severity | Primary fix |
|---|---|---|---|
| Broken object authorization | One test tenant reads or changes another tenant's object | High to Critical | Server-side ownership and permission checks |
| SQL injection | Input changes query behavior without damaging data | Medium to Critical | Parameterized queries and least-privileged DB access |
| Server-side request forgery | Server requests a tester-controlled callback URL | Medium to Critical | Destination allowlist and network egress controls |
| Cross-site scripting | Inert lab payload executes in the intended victim context | Low to High | Context-aware output encoding and safe DOM APIs |
| Authentication or session failure | Revoked session remains usable or reset flow is bypassed | Medium to Critical | Server-side invalidation and robust recovery controls |
| Security misconfiguration | Debug route, unsafe default, or sensitive file is exposed | Low to Critical | Secure defaults, environment review, automated policy checks |
| Supply chain failure | Untrusted build input reaches a release without verification | Medium to Critical | Artifact integrity, dependency controls, isolated builds |
| Unsafe exception handling | An error causes a control to fail open or leaks sensitive detail | Low to High | Fail closed, bounded errors, consistent state cleanup |
Safe proof-of-concept examples, evidence, and fixes
A proof of concept should answer three questions: is the weakness reachable, can it cross a security boundary, and what is the least harmful evidence that proves the impact? The examples use fictional endpoints and placeholders.
Broken access control: cross-tenant invoice access
A user in tenant A requests an invoice they own, then substitutes an identifier belonging to a synthetic tenant B account supplied for the test.
GET /api/invoices/inv_test_b_204
Authorization: Bearer <tenant-a-test-token>- Evidence
- Response status, the tenant-A identity, the synthetic tenant-B object ID, and a redacted field proving the wrong record was returned.
- Why severity changes
- Read-only access to one low-sensitivity object differs from enumerable access to all customer records or write access to billing instructions.
- Fix and retest
- Enforce object ownership in trusted server-side code. Retest read, update, export, and delete across every affected role and adjacent endpoint.
OWASP lists user-controlled identifiers and missing API access checks as common broken access control failures. See OWASP A01:2025.
SQL injection: input changes a database query
In a local or isolated test environment, a search parameter produces a different result when it contains a quotation mark or a benign boolean expression. The tester does not dump records or modify data.
GET /lab/products?category=books%27%20OR%20%271%27%3D%271
Host: app.example.test- Evidence
- The original request, one controlled variation, response difference, server-side error correlation if available, and the affected query location.
- Why severity changes
- Risk rises with unauthenticated reachability, sensitive data, database privileges, write capability, stacked queries, or a path to operating-system commands.
- Fix and retest
- Use parameterized queries, remove unnecessary database privileges, and retest every query path that shared the unsafe construction pattern.
Server-side request forgery: outbound callback from the server
A document-preview feature accepts a URL. The proof uses a domain controlled by the tester and a unique token. Receiving the callback shows that the application server made an outbound request.
POST /api/previews
Content-Type: application/json
{"url":"https://callback.example.test/pentest-token-7f2"}- Evidence
- The submitted URL, callback timestamp, source network detail, unique token, and application response. Avoid contacting cloud metadata services or internal systems unless the scope expressly authorizes it.
- Why severity changes
- An outbound request to the public internet may be Medium. Access to internal control planes, trusted services, credentials, or sensitive response bodies can raise the impact sharply.
- Fix and retest
- Allow known destinations and schemes, resolve and validate the final IP, block private and special-use ranges, constrain egress, and revalidate after redirects.
Cross-site scripting: untrusted HTML executes in a browser
In a test-only record, a harmless payload shows that attacker- controlled markup reaches an executable browser context. Do not collect cookies, tokens, or user data.
<img src=x onerror="document.body.dataset.poc='executed'">- Evidence
- Input location, storage behavior, rendered context, affected roles, browser result, and the response headers or content security policy in effect.
- Why severity changes
- Self-XSS in an isolated view may be Low. Stored execution in an administrator's origin with sensitive actions can be High.
- Fix and retest
- Apply output encoding for the destination context, use safe DOM APIs, sanitize intentionally supported HTML, and deploy a strict content security policy as defense in depth.
Session failure: a logged-out token remains valid
The tester signs in to a dedicated account, records one authenticated request, logs out, then repeats that same request. A successful response can show that server-side revocation did not occur.
1. GET /api/profile → 200 (authenticated)
2. POST /auth/logout → 204
3. GET /api/profile → 200 (old token still accepted)- Evidence
- Token type and lifetime, logout response, repeat request, session state, and whether password reset or administrative revocation has the same behavior.
- Why severity changes
- A short-lived low-privilege token differs from an indefinite administrator session that survives password reset and account suspension.
- Fix and retest
- Invalidate stateful sessions on the server. Keep access tokens short-lived, rotate refresh tokens, and verify logout, password reset, role change, and account disable flows.
OWASP includes session invalidation and authentication lifecycle failures in its guidance. See OWASP A07:2025.
Vulnerability severity levels and CVSS v4.0
The Common Vulnerability Scoring System (CVSS) gives teams a common way to describe technical severity. FIRST's CVSS v4.0 specification maps numeric scores to the following optional qualitative ratings.
| Rating | CVSS score | Working interpretation |
|---|---|---|
| None | 0.0 | No security impact under the scored conditions |
| Low | 0.1–3.9 | Limited impact or demanding prerequisites |
| Medium | 4.0–6.9 | Meaningful impact with constraints or user involvement |
| High | 7.0–8.9 | Serious confidentiality, integrity, or availability impact |
| Critical | 9.0–10.0 | Severe impact with a highly effective attack path |
The score bands come directly from the FIRST CVSS v4.0 specification. The interpretations are practical summaries, not official CVSS definitions.
Five questions to ask after calculating a score
- Which asset is affected? A test tenant and the production identity service do not carry the same business risk.
- What data or action is exposed? Public catalog data, personal records, signing keys, and money movement demand different responses.
- How large is the blast radius? One object, one tenant, every tenant, or the control plane?
- Which prerequisites are realistic? Consider authentication, privileges, user interaction, network position, and required timing.
- Which controls change the current risk? Feature flags, network isolation, monitoring, rate limits, and rapid token expiry may affect priority without removing the root flaw.
Use a reproducible technical score, then document environmental and business context. Do not quietly lower a score because a fix is inconvenient. If a compensating control changes the immediate priority, name the control and its owner.
How lower-severity vulnerabilities form a critical attack path
Findings should also be tested in combination. A public debug response might reveal an internal service name. A server-side fetch feature might reach that service. A missing authorization check on the internal route might then expose customer records. Each condition viewed alone can understate the combined impact.
Verbose error reveals an internal route
Server-side fetch can reach the route
Internal route trusts network location
Synthetic cross-tenant record is returned
A responsible proof uses a controlled callback and synthetic data, then stops. The report should rate the demonstrated chain and preserve each underlying weakness so owners can remove every link.
What a useful penetration test finding contains
A good finding lets an engineer reproduce the condition without reverse-engineering the report and lets a risk owner understand why it matters.
Cross-tenant invoice access
- Affected scope
GET /api/invoices/:id, member and manager roles- Precondition
- Authenticated user and a valid invoice identifier
- Proof
- Tenant A token returned one synthetic tenant B invoice
- Impact
- Unauthorized disclosure of billing data across tenants
- Root cause
- Lookup constrained by invoice ID but not authenticated tenant ID
- Remediation
- Central server-side ownership check plus negative authorization tests
- Retest
- Pending on original route and adjacent export endpoint
The final report should also record the testing method, limitations, affected versions, evidence handling, and severity vector or rationale. For audit-driven work, connect findings and remediation status to the evidence package described in our SOC 2 penetration testing guide.
Remediation and retesting: when is a finding closed?
A code change can remove the reported symptom while leaving the same weakness in another route. Retesting should verify the original proof, the root-cause fix, nearby variants, and regression coverage.
The original proof no longer succeeds under the same preconditions.
The fix enforces the intended control on the server, not only in the interface.
Adjacent endpoints and roles using the same pattern have been checked.
Negative security tests cover the failed boundary.
Logs and alerts record meaningful exploitation attempts where appropriate.
The retest result, date, tester, and deployed version are attached to the finding.
If the attack surface changes frequently, one annual snapshot may not describe current risk. Continuous testing can revisit changed code and preserve a history of validation, remediation, and human approval. See how Helix approaches continuous penetration testing.
Frequently asked questions
What are the most common web application vulnerabilities?
Common classes include broken access control, security misconfiguration, injection, authentication failures, cryptographic failures, software supply chain failures, insecure design, integrity failures, missing security alerting, and unsafe exception handling. The OWASP Top 10:2025 groups current web application risks into these categories.
What is a proof-of-concept exploit?
A proof-of-concept exploit is the smallest controlled demonstration that a vulnerability is reachable and has a stated impact. It should use authorized targets, synthetic data, and the least harmful action needed to prove the finding.
What are the CVSS severity levels?
FIRST's CVSS v4.0 qualitative scale is None 0.0, Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9, and Critical 9.0 to 10.0. An organization should still consider its own environment and business impact when prioritizing work.
Is every SQL injection vulnerability critical?
No. Severity depends on reachability, privileges, user interaction, data and system impact, and environmental controls. SQL injection that exposes a production customer database may be critical; a constrained query against public data may rate lower.
Can automated scanners find every web vulnerability?
No. Scanners are useful for coverage and known patterns, but often lack the product context needed to prove tenant isolation failures, business-logic abuse, multi-step attack paths, and meaningful impact. Findings should be validated before reporting.
Primary sources
- OWASP Top 10:2025 introduction and category list
- OWASP A01:2025 Broken Access Control
- OWASP A05:2025 Injection
- OWASP A07:2025 Authentication Failures
- FIRST CVSS v4.0 specification
OWASP categories do not assign a severity to a specific finding. The example ranges in this guide are contextual illustrations; calculate and document the vector for each real result.