Web app testing
Web application penetration testing, role by role.
A tester signs in as each role you give us and checks what that role can reach, from password reset to payment approvals.
What a tester checks on web applications.
Everything a signed-in user touches: sign-in and sessions, the boundary between accounts and tenants, input handling, file uploads, and the business rules behind checkout and admin.
Sign-in and sessions
We test sign-in, multi-factor and how long a session stays valid.
For example, Cookie: sidAccess between users
Whether one user, role or tenant can reach data that is not theirs.
For example, /w/{id}/users.csvSee the sample findingInjection and input flaws
Injection, cross-site scripting and other ways input becomes code.
For example, display_nameBusiness logic
Payments, approvals and limits, tested for steps a user can skip.
For example, POST /checkoutPassword reset and recovery
Password reset, email change and recovery, from request to new session.
For example, POST /resetFile upload and handling
What the app accepts as a file, and what it does with it.
For example, POST /avatarAdmin and staff routes
The admin tools and staff routes your customers never see.
For example, GET /admin/usersOutbound requests
Whether the server can be made to fetch a URL an attacker chooses.
For example, fetch?url=
What we need from you
- An account for each role
- The address of the app
- A test window you agree
On live systems
Live systems by default, inside agreed windows, with a named contact and no destructive actions.
How we test it, step by step.
A tester uses the app as each role and works the leads worth chasing by hand. Each one is proved with a request you can replay and written up with its fix.
A tester leads every step. AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.
Map every role
What the tester does
We sign in as each role you give us and map what it reaches.
What you learn
A picture of who can reach what, before we push on anything.
Work each lead
What the tester does
We change one value or skip one step, then read what the server returns.
What you learn
Which checks hold on the server, and which only sat in the screen.
Prove the reach
What the tester does
We reproduce each finding with a request you can replay yourself.
What you learn
A confirmed finding, with the request and response that show it.
Write the fix
What the tester does
We write the server-side change for the engineers who own that code.
What you learn
The route where the check belongs, and how to confirm it holds.
Three attack paths from one ordinary login.
Each sample starts with one signed-in account and ends with data or an action that belongs to someone else.
- Sample
One member reads another's data
A trial user edits the workspace number in a download link. The file belongs to another customer.
- Sample
A checkout step is skipped
A shopper skips the approval step and sends the final request. The paid plan is placed at the free price.
- Sample
An old reset link still works
An unread reset email holds a link that never expires. Whoever finds it can take the account.
One sample finding, in full.
We take an account for each role you name, then try to reach another account's data by changing an ID or replaying a request.
Acme Corp is a fictional client. Every sample on this page is illustrative, never client data.
Any member can download another workspace's user list
WhereGET /w/{id}/users.csv
Request as a member of A
GET /w/4410/users.csv HTTP/2Host: app.acme-corp.comCookie: sid=<member of A>
Response: another workspace's users
HTTP/2 200 OKContent-Type: text/csvemail,role [redacted]
- Business risk
- Any signed-in member of one customer could download another customer's full user list.
- Fix
- Check the caller belongs to the workspace, not only that they signed in.
Removed: requireSignedIn(req)
Added: requireMember(req, workspace)
Checked by a tester before it reached the report.
What lands on your desk.
Each finding names the endpoint, the data it exposed and the server-side check that closes it. Leadership receives an executive briefing.
Report
Findings, proof and fixes
Fix guidance
A server-side check for every finding
Executive briefing
Which roles reach what data
One retest within 30 days of the report
Workspace check holds
Who it suits, and when to book it.
Multi-tenant products, where tenant isolation and role checks decide which customer reads which data.
SaaS products
Multi-tenant apps where roles and admin routes decide who sees what.
Internal platforms
Staff tools behind single sign-on, where one role can reach too far.
Regulated products
Fintech and health teams who need an outside test before an audit.
When to book it
- Before a launchTest a new product before the first customer signs in.
- After a big changeA new role model or payment flow changes who can reach what.
- For a security reviewA customer or their questionnaire asks for an outside test.
- Before an auditYour auditor wants evidence of an independent penetration test.
- When releases speed upLast year's test no longer describes the app your customers use.
Aligned with OWASP and NIST for web applications.
Testing follows these standards, so your team can read the method against references it already uses.
OWASP Top 10
Open Worldwide Application Security Project (OWASP) Top 10
The most critical risks to web applications, ranked.
OWASP ASVS
OWASP Application Security Verification Standard (ASVS)
Security requirements an application is verified against, in three levels.
NIST SP 800-115
National Institute of Standards and Technology (NIST) Special Publication 800-115
The technical guide to information security testing and assessment.
Aligned with, never certified by. Names belong to their owners; no endorsement implied.
Questions before scoping.
Roles, business logic, live systems, access and what you receive.
We reply to every quote request within one business day, from info@greysurface.com.
Do you test as each kind of user?
Yes. We test signed out, then signed in with an account for each role you name, and record what each role can reach.
Do you test payments and approvals?
Yes. We test the business logic behind checkout, refunds and approvals, where skipping or repeating a step lets a user pay less or gain more.
Do you test the live web app?
Yes, by default. We test your live app inside a window you agree, with a named contact and no destructive actions.
What access do you need from us?
An account for each role, the address of the app and a test window. If a flow needs test data, such as a card in a payment sandbox, we agree that first.
What does the report contain?
Proof of exploit, the business risk and a fix for each finding, most serious first. Leadership receives an executive briefing, and one retest follows within 30 days of the report.
How should we prepare?
Working accounts for each role and a stable environment. A short walkthrough of the main flows helps; without one, we map them ourselves.