Web Security Testing in Practice

Why it matters

Careful code is easily undone by how it is deployed and what it is built from. A debug page left on, a default admin account or an old library with a published vulnerability opens a door without a single coding mistake in the feature you tested. Both are OWASP Top 10:2025 categories, Security Misconfiguration (A02:2025) and Software Supply Chain Failures (A03:2025), and both are easy to find with the automated tools that attackers point at public sites.

For the tester, the workflow makes the work safe and defensible: scope, environment, test accounts and the reporting channel are agreed before the first request, and afterwards you can show what was tested, how, and what was deliberately left out.

The workflow: seven steps in a fixed order

Permission comes before any request, low-impact checks before active ones, verification before reporting. The OWASP WSTG is the checklist behind the steps: tests grouped by area, each with an identifier such as WSTG-CONF-06, objectives and remediation advice. Pick the areas that fit the product's risks, mark each test done, not applicable or finding, and quote the identifier in the report.

Route a dedicated test browser through the intercepting proxy as set up in the lesson on intercepting proxies: its history becomes the map, its passive scanner flags missing headers and cookie attributes, and its scope setting keeps every request inside the authorisation.

• 1. Scope and permission: hosts, test window, excluded actions, an emergency contact and the channel for findings, in writing.
• 2. Map through the proxy: pages, roles, API endpoints, uploads, third-party scripts; a test account per role.
• 3. Passive pass: HTTPS redirect, HSTS, TLS 1.2 or 1.3, security headers and cookie attributes on every page type.
• 4. Configuration probes: default accounts, debug output, errors, directory listing, HTTP methods, admin paths.
• 5. Components: triage the dependency scan and the SBOM of the build under test.
• 6. Scanner and manual tests: an active DAST scan, which can create records and send e-mails, only where the scope allows; manual WSTG tests for access control, business logic and CSRF, which scanners cannot judge reliably.
• 7. Verify, map, report, retest: reproduce each lead by hand, name its Top 10 category, file it privately, retest after the fix.

Try it: Redirect Checker Try it: Security Header Analyzer Try it: Cookie Analyzer

Security misconfiguration and failing safely

A misconfiguration is a weakness in how software is set up, not how it is coded: a framework default, a feature nobody switched off, a setting copied from development. Each check is an ordinary request and a careful reading of the response.

Failing safely is the other half. A10:2025 Mishandling of Exceptional Conditions covers unhandled exceptions, checks that fail open (access granted because the permission service timed out) and operations left half-done. Provoke the condition safely, with a malformed value or a dependency stub that times out on the test environment, and check that the request is refused, the message is generic and no partial record remains.

• Default accounts (WSTG-ATHN-02): try only the vendor's documented defaults on each console the map found, a few attempts at most. Expected: rejected.
• Debug modes: debug pages and toolbars, source maps, test-only endpoints. Confirm on the release candidate that the release configuration switches them off.
• Stack traces and verbose errors (WSTG-ERRH-01): send a wrong type (/api/orders/abc), a missing field, an over-long value. Expected: a 4xx status and a short message with a reference id; no stack trace, SQL, file paths or versions.
• Directory listing: request folders such as /static/. Expected: 403 or 404, not an "Index of" page.
• HTTP methods (WSTG-CONF-06): send OPTIONS and read Allow; TRACE should be refused and unneeded methods should get 405. Try PUT or DELETE only on a record you created.
• Admin and diagnostic endpoints (WSTG-CONF-05): consoles and detailed health, metrics or status pages must not answer from the internet without an admin login.
• Security headers: recorded in the passive pass; they often go missing on error pages, redirects and API responses.

Try it: API Request Builder

Vulnerable and supply-chain components: SCA, CVE, CVSS and SBOM

Many components of a web application arrive indirectly, through other components. A03:2025 Software Supply Chain Failures covers known-vulnerable, unmaintained, untracked or compromised components and build steps. The scan usually runs in the pipeline; the tester reads it, triages it with a developer and brings it to the release decision.

Triage each alert with four questions. Is the vulnerable version in the shipped build, or only in a development dependency? Is the vulnerable code reached the way the product uses the component? Is a fix available, and what does it change? Is the vulnerability known to be exploited (the advisory, or a public list such as CISA's Known Exploited Vulnerabilities catalog, says so)? The outcomes: fix now, fix in a planned release, not affected with the reason recorded, or false positive. Accepting a risk is the security or product owner's call.

• SCA (software composition analysis) reads the dependency files (for example package.json and its lock file package-lock.json, or a Maven pom.xml), lists every direct and transitive dependency with its version and matches them against published advisories.
• A CVE ID (CVE-<year>-<number>) names one publicly disclosed vulnerability; it links the advisory, the scanner and the fix, and lets you merge duplicates.
• CVSS, the Common Vulnerability Scoring System maintained by FIRST, gives a base score from 0.0 to 10.0: None 0.0, Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9, Critical 9.0–10.0. The vector says why: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8) means a network attack, low complexity, no privileges, no user action, and high impact on confidentiality, integrity and availability. Check the version prefix (3.1 or 4.0) before comparing scores.
• CVSS calls these bands severity ratings, but the base score rates the vulnerability in general, not in your product: it is an input to the severity of your defect report, not that severity.
• An SBOM (software bill of materials) lists the components of one build with versions, suppliers and dependency relations, in a standard format such as SPDX or CycloneDX, so "are we affected?" becomes a search.

Try it: JSON Tree Viewer Try it: JSON Diff

Mapping findings to the OWASP Top 10:2025

Each report entry names the WSTG test (how it was checked) and the Top 10 category with its year (what kind of risk it is). When a finding fits two categories, choose the root cause: a debug page left on is A02, a stack trace from an unhandled exception is A10.

• A02:2025 Security Misconfiguration: default accounts, debug modes, verbose error settings, directory listing, unneeded methods, exposed admin or diagnostic endpoints, missing headers and cookie attributes.
• A10:2025 Mishandling of Exceptional Conditions: leaked stack traces, fail-open checks, half-done operations.
• A03:2025 Software Supply Chain Failures: vulnerable, unmaintained or untracked components and build tools.
• A04:2025 Cryptographic Failures: plain HTTP, outdated TLS.
• A01:2025 Broken Access Control: an admin endpoint that answers without the right role; findings from the manual role tests.
• A08:2025 Software or Data Integrity Failures: scripts from an untrusted CDN without an integrity check, unverified updates.

Worked example: triage and report a scanner finding

A security report is a map for an attacker. File it only in the channel the scope names, usually a restricted tracker project, never a public issue or a team chat. Redact session identifiers, tokens, passwords and personal data, and prove only as far as needed: one response that shows another user's e-mail address is proof; downloading the table is an incident.

On the bookshop check, the dependency scan of build 412 raised two alerts; the developer and the tester checked both against the SBOM of the build. The names and the advisory ID are invented.

• The other alert, a test-runner library rated 9.8 Critical, was recorded as not affected: a development dependency absent from the shipped SBOM. Its upgrade was still scheduled, because it runs on CI machines that hold secrets.
• The 8.8 alert became the finding because the vulnerable version ships and any logged-in user reaches it: presence and reachability decided, not the score. The proposed severity is Critical on the team's scale, not the CVSS band High, because per the advisory any logged-in user could run code on the image service.
• Retest on build 413: rescan and confirm the fixed version in its SBOM before closing. A flaw in the component itself goes to its maintainer through the published security contact, never a public issue.

Finding WS-05  Vulnerable image library in avatar upload   Severity: Critical (proposed)
Category:  A03:2025 Software Supply Chain Failures
Source:    dependency scan (SCA), build 412
Component: acme-img-resize 3.2.0, transitive via avatar-service 1.4.2, runtime
Advisory:  CVE-YYYY-NNNNN  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  8.8 High
Fixed in:  acme-img-resize 3.2.4 (per the advisory)
Triage:    in the SBOM of build 412; reached on every avatar upload, which any
           logged-in user can make. No exploit attempted.
Impact:    per the advisory, a crafted image can run code on the image service.
Fix:       upgrade avatar-service, or pin acme-img-resize >= 3.2.4; rescan.
Evidence:  scan report and SBOM excerpt attached; no tokens or user data in them.
Status:    filed as SEC-231 (restricted security project); retest on build 413.

Frequently asked questions

References

• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• OWASP Top 10:2025OWASP Foundation · 2025The ten most critical web application security risks, with how to test for and prevent each.
• OWASP Cheat Sheet Series: Error HandlingOWASP FoundationError responses that help the caller without leaking stack traces, versions or internal paths.
• NIST SP 800-115: Technical Guide to Information Security Testing and AssessmentNIST · 2008How to plan and run security assessments: review, target identification, vulnerability validation and reporting.