Web application penetration testing
Gjethe tests web applications the way attackers approach them: logins and sessions, access between users and roles, input handling, payments and business logic. Testing follows OWASP guidance, every finding comes with evidence and a fix, and a retest confirms the problems are gone.
- Free first consultation
- Written quote for your project
- Flexible payment milestones
At a glance
- Standards
- OWASP Top 10, OWASP ASVS, WSTG
- Focus
- Access control, logic, data exposure
- Approach
- Usually grey box with test accounts
- Output
- Report, fixes and retest
Definition
What is web app penetration testing?
Web application penetration testing is a manual security assessment of a website or web app that tries to bypass its controls, reach data it should not expose and misuse its features, in order to find and fix exploitable weaknesses.
Most serious web application problems are not exotic. A user who can see another customer's invoice by changing a number in the address bar. An admin action that checks the menu but not the request behind it. A password reset that can be reused. These behave normally on the surface; the application just trusts the wrong thing. Finding them takes a tester who understands how the application is meant to work and deliberately checks whether the rules are enforced on the server, not only hidden in the interface.
Who is it for?
SaaS products
Several customers share one system, so the separation between accounts must be airtight.
Online stores and booking systems
Checkout, discounts, stock and payments are common targets for abuse.
Portals with personal data
Client, patient or member portals must show each person only their own information.
Teams before a major release
A test before launch is the cheapest moment to find structural problems.
What's included, and what you keep
What's included
- Mapping of pages, functions and user roles
- Authentication and password reset testing
- Session handling and token review
- Access control testing across users and roles
- Input handling and injection testing
- Output and client-side handling checks
- File upload and download handling review
- Business logic and workflow abuse testing
- Sensitive data exposure review
- Security headers, cookies and TLS review
- Third-party scripts and dependency review
- Report with evidence, fixes and a retest
What you receive
Handed over at the end. Yours to keep.
- Web application test report
- Findings mapped to OWASP categories
- Clear write-up for each confirmed issue
- Prioritised fix plan
- Retest report
What we always check in a web application
- Can one user read or change another user's data?
- Can a normal user reach admin functions directly?
- Can logins be bypassed or reused?
- Do password resets and invitations expire properly?
- Is user input ever treated as code or queries?
- Can uploaded files cause harm on the server or to other users?
- Can prices, quantities or workflow steps be manipulated?
- Do responses contain data the page never shows?
Why access control problems are the most common finding
Broken access control sits at the top of the OWASP Top 10 for a reason. Frameworks handle many security tasks automatically, but they cannot know which records belong to which customer, or which buttons a manager may press. Those rules live in your code, written feature by feature, and one missing check is enough.
We test this systematically: important requests are repeated as other users and other roles, with identifiers changed, to see whether the server enforces the rule or only the interface hides the option. It is careful, repetitive work, and it is where many of the serious findings in modern applications come from.
OWASP Top 10 areas we cover
| Area | Example of what we check |
|---|---|
| Broken access control | Viewing or editing other users' records |
| Cryptographic failures | Sensitive data sent or stored without proper protection |
| Injection | Queries or commands built from user input |
| Insecure design | Workflows that can be abused by design |
| Security misconfiguration | Debug pages, default settings, verbose errors |
| Vulnerable components | Outdated libraries with known weaknesses |
| Authentication failures | Weak login, session or reset handling |
| Software and data integrity | Unsafe updates or untrusted third-party code |
| Logging and monitoring | Attacks that would go unnoticed |
| Server-side request forgery | The server fetching addresses an attacker controls |
Testing the parts of an app that scanners skip
Automated scanners are good at spotting reflected input and known patterns, but they do not understand what your application is for. They cannot tell that a discount code should only apply once, that a draft invoice should not be payable, or that a support agent should see tickets but not change billing. Those rules are specific to your business, and breaking them is exactly how real abuse happens.
We spend most of a web application test on this human side: reading how each feature is meant to work, then checking whether the server actually enforces it when a request arrives out of order, with a changed value, or from the wrong account. It is slower than a scan and far more useful, because it reaches the problems that cost money and trust rather than the ones a tool would have flagged anyway.
How web app penetration testing works, step by step
Every step has a clear output you can review. Timing is agreed in your quote.
- 1
Scope
Application, environments, roles and test accounts agreed in writing.
- 2
Map
Every page, request and role catalogued before testing starts.
- 3
Test
Manual testing across the OWASP areas and your business logic.
- 4
Verify
Each finding confirmed carefully, with safe evidence of impact.
- 5
Report
Findings, risk ratings and fixes your developers can follow.
- 6
Retest
Fixes verified and the report updated.
Tools, and what shapes your quote
Pricing is based on your project and agreed in your quote. These are the things that move it.
| Factor | Why it matters |
|---|---|
| Size of the application | More pages, forms and endpoints mean more to map and test. |
| Roles and tenants | Each role and customer boundary multiplies the access control tests. |
| Workflows | Payments, approvals and multi-step processes need careful logic testing. |
| Environment | A stable staging copy speeds testing; fragile production needs more care. |
| Source code access | A white box review alongside testing adds depth and effort. |
| Area | Tools |
|---|---|
| Testing proxy | Burp Suite, OWASP ZAP, browser developer tools |
| Discovery | content discovery tools, subdomain tools |
| Support | Postman, custom scripts |
| Guidance | OWASP WSTG, OWASP ASVS, OWASP Top 10, CVSS |
Common mistakes to avoid
What we see go wrong most often, and how a good project avoids it.
Hiding buttons instead of checking permissions
If the server does not verify each request, anyone who finds the address can use the function.
Trusting values from the browser
Prices, user IDs and roles sent by the browser can be changed; the server must decide them.
Verbose error messages
Stack traces and database errors hand attackers a map of your system.
Testing with one account only
Without accounts for several users and roles, access control problems stay hidden.
Frequently asked questions
Do you need our source code?
No, most web app tests are grey box with test accounts. Source code access helps us go deeper and is useful for critical applications.
Can you test a single-page app built with React or Vue?
Yes. The interface runs in the browser, so we focus on the APIs behind it, where the real security decisions must happen.
Do you test on production or staging?
Either. Staging is safer when it mirrors production closely. If we test production, we agree windows and avoid actions that could affect real customers.
Will you create real orders or emails?
Only where agreed. We use test accounts and test payment modes, and we clean up test data we create.
How do you rate risk?
Each finding gets a rating based on how easily it could be exploited and what an attacker could gain, using CVSS where it fits alongside plain-language business impact.
Is OWASP Top 10 coverage enough?
It is a strong baseline. We also test your specific business logic, which no generic list fully covers.
Can you retest after we fix things?
Yes, a retest of the findings is included and the report is updated with the results.
Can you also fix the issues?
Yes. As a development team we can implement the fixes, or review your team's fixes before the retest.
Related services
Penetration Testing
Authorised, scoped security tests with a fix-it report.
API Security Testing
REST and GraphQL tests against the OWASP API Top 10.
Secure Code Review
Review your codebase for security flaws before release.
Vulnerability Assessment
Find, rank and plan fixes for known weaknesses.
Web Applications & SaaS
Portals, dashboards and subscription products.
Website Security
Hardening, malware clean-up and security reviews.
Web App Penetration Testing by industry
Find out what your web app really exposes.
Tell us what you need. You get an honest assessment, a clear plan and a written quote. The first consultation is always free.
- What happens next
- 1You tell us what you need
- 2We aim to reply within 24 hours with questions
- 3You get a written quote for your project