Web application testing that finds what scanners can't.
We test your application the way an attacker would: signed in and signed out, across every role, chasing the business-logic and authorization flaws automated tools never reach.
- Before a launch or release:
- find the serious flaws while they're cheap to fix.
- A customer asked for a report:
- a reproducible report and an attestation letter you can share.
- Manual testing across every user role
- Findings mapped to the OWASP Top 10
- Reproduction steps and fix guidance for each finding
- Retest included, report reissued
What is a web application penetration test?
A penetration test is a controlled attack on your application by a person, to find the flaws that matter before someone hostile does. For web apps we work against the OWASP Top 10 and go beyond it: authorization, business logic and the APIs behind the screen. We confirm each finding is real and show what it lets an attacker do.
What we test
- Sign-in and sessions
- Roles and permissions
- Forms and file uploads
- REST and GraphQL APIs
- Third-party integrations
- Browser-side code
What you get back
- Confirmed, reproducible findings
- Severity tied to your risk
- Specific fix guidance
- A walkthrough with engineers
- A retest of the fixes
- An attestation letter
WEB
Findings your engineers can reproduce
A scanner lists possibilities. A tester proves them: each finding comes with the steps to reproduce it, the evidence, and what an attacker could do with it.
A retest is included, so you can show the issue is closed, not just assume it.
Six areas every web test covers
Injection
SQL, NoSQL, command and template injection, plus file handling.
Authentication
Credential handling, MFA bypass, sessions and password reset.
Authorization
Privilege escalation and direct-object access across roles.
Client side
XSS, CSRF, clickjacking and risky front-end dependencies.
APIs
REST and GraphQL: mass assignment, rate limits, exposure.
Where web testing matters most
- SaaS products
- E-commerce
- Fintech
- Health platforms
- Internal portals
- Customer APIs
The trigger is usually a product launch, a customer security review, a compliance audit that asks for a penetration test, or a major change to how users sign in.
Browse plain-language security guides in the Resources libraryWhat sits in scope of a web application test?
Three layers, and an attacker moves between them: the people who use the app and the roles they hold, the application itself, and the services it depends on. Scope covers the layers that matter for your risk.
01 · The people
Users and roles
- Anonymous visitors
- Customers
- Staff and admins
- Partners with access
Each role is tested, because most serious flaws are a role reaching what it shouldn't.
02 · Your application
Pages, logic and sessions
- Sign-in and password reset
- Forms and uploads
- Workflows and payments
- Browser-side code
Where business logic lives, and where scanners stop helping.
03 · What it relies on
APIs and integrations
- REST and GraphQL endpoints
- Third-party services
- Storage and queues
Tested directly, outside the limits the front end puts on a request.
If your app holds customer data, takes payments, or has more than one user role, a test will find things your team can't see from the inside.
Third-party services and APIs your app calls are part of your attack surface. We agree up front which are in scope and which belong to the vendor.
How a web application test runs
Six steps, each with a named output and a clear ask of your team. Scoping and reconnaissance set the ground; manual testing is the core.
- Scope
Scoping
We agree targets, user roles, test windows and rules of engagement in writing before anything starts.
- Targets and roles
- Test accounts
- Test windows
- Rules of engagement
- You get
- A written scope and rules of engagement.
- You provide
- Credentials for each role and a technical contact.
- Recon
Reconnaissance
We map the application: routes, parameters, roles, third-party integrations and the technology behind them.
- Routes and parameters
- Roles
- Integrations
- Technology stack
- You get
- A map of the attack surface.
- You provide
- Architecture notes, if you have them.
- Baseline
Automated baseline
Tooling clears the well-known ground quickly, so the manual hours go to the findings that need judgment.
- Known weaknesses
- Configuration checks
- Dependency risk
- Header and TLS review
- You get
- A cleared baseline and a list of leads.
- You provide
- Nothing beyond the agreed access.
- Manual
Manual testing
The core of the work: business logic, chained flaws and authorization gaps, tested by hand across every role.
- Business logic
- Authorization
- Chained flaws
- Session handling
- You get
- Confirmed findings as they are found.
- You provide
- Answers to questions about intended behaviour.
- Exploit
Exploitation & impact
We confirm each finding is real and show what it lets an attacker do, so severity reflects your risk, not a generic score.
- Proof of exploit
- Impact analysis
- Chaining
- Severity rating
- You get
- Evidence and an impact statement per finding.
- You provide
- A contact for critical findings, who we call the same day.
- Report
Report & retest
You get reproducible findings with fix guidance, a walkthrough with your engineers, and a retest once you've fixed them.
- Findings report
- Walkthrough
- Retest
- Attestation letter
- You get
- A report, a walkthrough and a reissued report after retest.
- You provide
- Engineers on the walkthrough, and the fixes to retest.
There's no one-size timeline: it depends on the number of roles, endpoints and workflows in scope. You get a firm estimate in writing during scoping, before any work begins.
What you receive
The engagement ends in one test file. Each item is paired with the question a reviewer or a customer's security team asks about it.
Each finding comes with the specific fix, and a retest that verifies it. We reissue the report, so the evidence that it is closed exists before anyone asks.
A penetration test isn't a certificate; it's evidence. Customers, auditors and your own team judge it by how reproducible the findings are and whether the fixes were verified.
01, Report phase: Executive summary
Written for non-technical stakeholders, with the headline findings.
02, Scope phase: Scope and rules of engagement
Targets, roles, windows and limits, as agreed in writing.
03, Recon phase: Attack-surface map
Routes, roles and integrations found during mapping.
04, Manual phase: Findings with reproduction steps
Each finding with steps, evidence and CVSS scoring.
05, Exploit phase: Impact statements
Severity tied to your data and workflows.
06, Report phase: Remediation guidance
Specific fixes mapped to each finding, not general advice.
07, Report phase: Retest report
Every fix verified, and the report reissued.
08, Report phase: Attestation letter
A letter suitable for security questionnaires.
Illustrative example, not client data
What one finding looks like
- Title
- Order details readable by another customer
- Area
- Authorization (direct object reference)
- Severity
- High (CVSS scored)
- Steps
- Sign in as user A, change the order ID in the request
- Impact
- Any signed-in user can read other customers' orders
- Fix
- Check order ownership on the server for every request
Four common web testing misconceptions
Each one is common, reasonable, and the reason a test misses what matters.
Assumption 01
Assumption: A vulnerability scan is the same as a penetration test.
What testing actually shows
A scan lists known weaknesses. A test chains them and probes business logic that tools can't model.
Assumption 02
Assumption: Testing only works if we hand over nothing.
What testing actually shows
Testing without credentials only shows what an anonymous attacker sees, which misses most authorization flaws.
Assumption 03
Assumption: It will take our application down.
What testing actually shows
We avoid denial-of-service testing unless you ask, and agree rate limits and windows first.
Assumption 04
Assumption: A clean report means we're secure.
What testing actually shows
A report describes the app at the time it was tested. Re-test after significant change.
Heard one of these from your team? A scoped web test shows where you really stand.
Get a web application test scopedWhat you can hold us to.
We don't publish client logos next to findings; we keep our clients' security posture private. These are the commitments we make instead.
Our commitments
Senior testers on the work
Every engagement is led by experienced practitioners, not handed to a junior running a scanner.
Peer-reviewed reports
Every report is peer-reviewed before it reaches you.
Written scope and rules
You know what is tested, when, and what happens if scope changes, before work starts.
Retesting included
We verify your fixes and reissue the report, so closure can be shown.
Auditify Security's Web Application Security Testing is second to none! We were amazed at how thoroughly they examined our app for vulnerabilities. They provided actionable insights that helped us patch critical issues quickly. The team was professional, responsive, and easy to work with.
Want to speak to a client? Ask for a reference while we scope your work and we'll arrange it directly.
Ask for a referenceWeb testing questions buyers ask
Do you test production or staging?
Either; staging is safer for destructive cases.
Staging is usually preferred, but it must mirror production closely enough to be meaningful. If we test production, we agree limits on data-changing actions in advance.
Find the flaws before someone else does.
Send the basics
What you want tested (an app, its roles and its APIs), who uses it, and any deadline such as a customer review or an audit.
We scope the work
We respond within 24 hours, then agree targets, access and rules of engagement in writing.
Your test, then your retest
You get a reproducible report, a walkthrough with your engineers, and a retest of the fixes.
- Before a launch or release:
- find the serious flaws while they're cheap to fix.
- A customer asked for a report:
- a reproducible report and an attestation letter you can share.
We test and report. We don't change your systems; fixes are made by your team, and we verify them.