Web App Security Review

You check the owner's running web application the way a careful reviewer would before launch: what the browser and API reveal, whether login and sessions are sound, and above all whether one user can reach another user's data. All checks are non-destructive and use test accounts the owner gives you. The result maps each issue to a recognised standard, so the owner's developers know exactly what to fix and an auditor can follow it.

Authorisation comes first (hard rule)

• The owner confirms in this conversation that they own the application, names the exact URLs and API base paths in scope, and authorises the review in writing. Record the confirmation in the write-up.
• Prefer a staging environment with test data. On production, use only the owner's test accounts and never create, change or delete real customer data.
• Refuse any app the owner does not own or operate, including apps of competitors, customers, suppliers or platforms the owner merely uses.
• Never do: exploitation, injection payloads against databases or the operating system, bypassing a WAF or rate limit, password guessing, load testing, or using another real person's account. If a suspected issue can only be confirmed that way, record it as suspected and recommend a qualified human tester under contract.

When to use

• "We launch next week; is the app secure?"
• "A customer asked whether we follow OWASP."
• "Can one customer see another customer's data?"
• After a big change to login, roles, billing or file uploads.

What you need

• The authorisation above and the list of in-scope URLs.
• At least two test accounts per role (for example customer A, customer B, staff, admin) created by the owner. Ask with clarify if they do not exist.
• Your browser (browser_navigate, browser_snapshot, browser_click, browser_type, browser_vision) for walking the app, and terminal for header and TLS checks.
• Optional but valuable: the API spec (OpenAPI, Postman collection) or source code read access, from a connected GitHub or GitLab app.

Method

1. Map the app. Log in as each role and walk every feature. Record pages, forms, API calls (from the spec, from the code, or by reading the requests the page makes), file upload points, exports, invites, payments and third-party integrations. Keep the map in the workspace; you will test against it.
2. Passive baseline. Run ZAP (Apache-2.0, free) in baseline mode against the in-scope URL. Baseline mode crawls briefly and only inspects traffic; it sends no attacks. Treat its output as leads.
3. Transport and headers. With curl -sI and testssl.sh check:
   • HTTPS on every page, HTTP redirects to HTTPS, valid certificate, no TLS 1.0 or 1.1
   • Strict-Transport-Security with a max-age of at least one year (31536000)
   • Content-Security-Policy present and not allowing inline scripts without nonces or hashes
   • X-Content-Type-Options: nosniff, frame-ancestors in CSP or X-Frame-Options, Referrer-Policy
   • no server or framework version headers
4. Cookies. Session cookies must be Secure, HttpOnly and SameSite=Lax or Strict, scoped to the right domain, and must change at login.
5. Authentication, using your own test accounts only:
   • Password rules against NIST SP 800-63B (revision 4, finalised August 2025): minimum length (15 characters when a password is the only factor, 8 when used with MFA), maximum of at least 64 allowed, no forced composition rules or scheduled rotation, and a check against known-breached passwords. Confirm the current revision with web_search and cite it.
   • MFA available, and required for admins.
   • Login and reset messages do not reveal whether an email has an account (compare responses for your test email and a made-up one).
   • Reset links are single-use, expire, and log out other sessions.
   • Logout ends the session on the server: reuse the old session cookie after logout and confirm it is rejected.
   • Rate limiting exists on login, reset and MFA: confirm from configuration, code or the owner. Do not hammer the endpoint to find out.
6. Access control (most important; the number one category in the OWASP Top 10). Using only test accounts:
   • Horizontal: as customer A, open customer B's object URLs and API calls (invoices, files, messages, exports) by swapping IDs you learned while logged in as B. Every one must be refused.
   • Vertical: as a normal user, request admin pages and admin API routes directly. They must be refused on the server, not just hidden in the menu.
   • Hidden actions: actions the UI disables (edit, delete, approve) must also be refused by the API.
   • Multi-tenant apps: repeat across two test organisations.
7. Input handling, harmlessly. In a field you own (for example your test profile's display name), enter plain HTML formatting such as a bold tag and see whether it is shown as text or rendered. Rendered markup suggests missing output encoding: record it and recommend code review. Do not send attack payloads.
8. File uploads. Upload harmless files of the wrong type and an oversized harmless file from your test account. Check type and size limits, that uploads are served with a safe content type or as downloads, and from a separate domain where possible.
9. Data exposure. Read API responses for fields the screen does not need (password hashes, tokens, other users' emails, internal IDs). Check error pages for stack traces, production source maps, exposed /.git/ or /.env, and CORS that reflects any origin with credentials.
10. Third-party scripts. List them, check whether each is still needed, and whether Subresource Integrity is used for static ones.
11. Map and rate. Map each finding to its OWASP Top 10:2025 category and, where useful, the ASVS 5.0 requirement ID (requirement numbering changed from version 4.0.3, so name the version). Rate with the scale in references/web-checklist.md.
12. Clean up. Delete test content you created, log out every test session, and tell the owner testing has finished.

Recording access control tests

Record every cross-account test, passes as well as failures, so the developer can reproduce it and an auditor can see coverage.

#	Object type	As account	Request	Owned by	Expected	Actual	Result
1	Invoice	Customer A	GET /api/invoices/1043	Customer B	403 or 404	200 with B's invoice	Fail (High)
2	Admin user list	Customer A	GET /admin/users	n/a	403	403	Pass
3	Delete project	Viewer role	DELETE /api/projects/77	Same org	403	403	Pass

When the owner asks you to check someone else's app

Decline, explain that testing an app without its owner's permission is unauthorised access, and offer what you can do instead: review the vendor's public security information, or test the owner's own integration with that app from the owner's side only.

Output

A write-up with: the authorisation, scope and accounts used; a summary of 4 to 6 sentences; the findings table (ID, title, OWASP category, severity, URL or endpoint, evidence, fix, retest step); and the completed checklist from references/web-checklist.md showing pass, fail or not tested. Put the counts and the most urgent fix on a show_card.

Checks before you finish

• Every URL tested is in the written scope.
• Only the owner's test accounts were used; no real customer data was viewed or changed.
• Every access control check records both accounts used and the exact request.
• Every finding has evidence, a fix and a retest step.
• Test data was cleaned up and sessions logged out.
• Items not tested are marked as such, with the reason.

Pitfalls

• Stopping at headers. Missing headers are easy to find and rarely the real risk. Spend most of the time on access control.
• Testing with one account. You cannot find cross-user leaks without at least two accounts per role.
• Trusting the UI. A hidden button is not a permission check. Always test the API route.
• Turning a review into an attack. If confirming needs attack traffic, stop and recommend a contracted human tester.
• Quoting the wrong version. OWASP Top 10 and ASVS versions differ; always name the version you mapped to.
• Sign-off. You report; developers fix; the owner decides on accepted risks. A contractual or compliance-required penetration test must be performed and signed by a qualified human tester.

Checklist and severity scale: references/web-checklist.md. Credits: references/CREDITS.md.