Web application testing: what testers check and how to fix it
In short: A web application test examines how an application handles identity, sessions, permissions, input, business rules and configuration. Testers map the application, test each area methodically, and report findings that developers fix at the root cause and protect with automated tests.
How a web test runs
Web applications are complex, change often and are directly exposed to the internet, so they are tested more than almost anything else. An authorised test usually uses a grey box approach: the tester gets accounts for each user role and sometimes API documentation. The work follows a checklist such as the OWASP WSTG, mapped to the OWASP Top 10 categories in the report.
Testers mostly work through an intercepting proxy, a tool that sits between their browser and the application so they can see and modify each request. Automated scanners help find simple issues, but most serious web flaws, especially access control and logic problems, are found by hand.
Areas checked and typical findings
| Area | Typical finding | Developer fix |
|---|---|---|
| Authentication | No rate limit on login; password reset tokens that do not expire | Rate limiting, MFA, short-lived single-use tokens |
| Sessions | Cookies missing Secure or HttpOnly flags; session not ended on logout | Secure cookie flags, server-side session invalidation |
| Authorisation | Changing an ID shows another user's data (IDOR) | Check ownership on the server for every object |
| Input handling | Cross-site scripting (XSS), SQL injection | Context-aware output encoding, parameterised queries |
| Business logic | Applying a discount code many times; negative quantities | Validate rules on the server, not in the browser |
| Configuration | Missing security headers, stack traces shown to users | Hardened configuration, generic error pages |
| Components | Outdated framework with known CVEs | Dependency scanning and regular updates |
APIs deserve the same attention as pages. Mobile apps and single-page applications call APIs directly, and authorisation checks are often weaker there.
Fixing findings well
Developers sometimes fix the exact example in a report rather than the underlying cause. If a tester shows one vulnerable parameter, assume the same pattern exists elsewhere. Good fixes are central: one authorisation check in shared code, one templating system that encodes output by default, one database layer that only allows parameters.
A quick check of response headers on your own site can be done from the command line:
curl -sI https://www.example.com | grep -iE "strict-transport|content-security|x-content-type|referrer-policy"Building testing into development
- Threat model new features before building them.
- Run static analysis (SAST) and dependency scanning in the build pipeline.
- Run dynamic scanning (DAST) against test environments.
- Commission manual tests for major releases and high-risk changes.
- Retest every high finding before release.
Tip: practise only on deliberately vulnerable training applications in your own lab. Testing a live website without permission is illegal in most countries, even if you report what you find.
Practice
Why are access control flaws usually found by manual testing rather than scanners?
A report shows XSS in a search box. What is the root-cause fix?
Why add an automated test after fixing a finding?
Key takeaways
- Web tests are usually grey box, with accounts for each role.
- Key areas: authentication, sessions, authorisation, input, logic and configuration.
- Access control and business logic flaws need manual testing.
- Fix the root cause centrally, then add a regression test.
- Build SAST, DAST and dependency checks into development.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.