A penetration test of the application you already have.
You have a live or nearly-live web application — built by you, your team, an agency or a freelancer — and you need to know how it fails before someone else finds out.
manual · written scope within two working days · sample report public
A customer, a partner or an investor wants to know the application has been tested, and “we ran a scanner” won't hold. You need findings a non-technical reader can act on, from a tester who can read your code and talk to your developers.
It's also for agencies and development teams who build well but don't test, and want a tester who works with their developers rather than around them.
what I test
Web applications and their APIs, by hand.
Tooling covers ground; it doesn't write the report. Every finding is reproduced by hand before it's written up. Mobile applications on request.
01
Authentication and session management
Signup, login, reset, tokens, logout — and what happens when they're wrong.
02
Access control across users, roles and tenants
Whether user A can read or change user B's data by changing an ID, a role or a request.
03
Input handling
Injection, cross-site scripting, request forgery, unsafe file handling.
04
Business-logic abuse
The flows a scanner can't see: prices, limits, states, sequences.
05
CORS and cross-origin behaviour
What another origin can read, send or trigger.
06
Headers, transport, cookies and the deployment surface
Security headers, TLS, cookie flags, information leakage, what the app exposes to the internet.
one finding, as you'd receive it
This is what a finding looks like.
From the sample report — a fictional target, the real format. Request, response, the line that gives it away, the severity, the fix.
The id is sequential and the server never checks who is asking. Every invoice on the platform is one number away. Severity: High (CVSS 7.5) · Broken object-level authorisation (OWASP API1). Fix: authorise on the server — invoice.ownerId === session.userId — and stop exposing sequential ids. Retested: fixed.
→ GET /api/invoices/10422 Authorization: Bearer <customer A>
← 200 OK { id: 10422, customer: "A", total: "₹2,40,000" }
→ GET /api/invoices/10423 Authorization: Bearer <customer A> ← next id, same token
← 200 OK { id: 10423, customer: "B", total: "₹1,10,000" }
what you receive
A finding, as it arrives.
Every finding in a report says what the issue is, what an attacker gains, exactly how to reproduce it, and how to fix it — ranked by real-world impact, never a scanner result passed through. This one is from the public sample; the whole 12-page report is linked under it.
IDOR on order endpoint exposes any customer's orders
Order API · CWE-639 · OWASP API1:2023
What the issue is
GET /v2/orders/{orderId} verifies that the caller is authenticated but never checks that the order belongs to them. Order IDs are sequential integers, so the entire order table can be walked by incrementing a number.
What an attacker gains
Any authenticated customer can read every order in the system: line items, totals, delivery addresses, phone numbers and email addresses. For a retailer this is a personal-data breach affecting the whole customer base, reachable from a free signup.
Reproduction
# authenticated as customer A (own order)
GET /v2/orders/10442 → 200 OK // expected
# same session, another customer's order
GET /v2/orders/10441 → 200 OK
{"orderId":10441,"customer":{"name":"[REDACTED]", …
A short script walking IDs 10000–10500 returned 500 of 501 records. Enumeration was stopped at that point and no data was retained; the redactions above are applied at capture.
How to fix it
Enforce ownership server-side on every object access — the query itself should be scoped to the caller, not filtered afterwards. Replace sequential identifiers with UUIDs so that enumeration is not trivially possible even if a check is missed in future.
-- scope the query, do not check after fetching
SELECT * FROM orders WHERE id = $1 AND customer_id = $2;
Add an automated test asserting that customer A receives 404 for customer B's order. This class of bug returns whenever a new endpoint is added, so the guard needs to be a test, not a code review habit.
Sample report · fictional target · every finding, payload and identifier in it is synthetic. Real reports go to the client and nowhere else.
what you get
A report you can act on. Then a call. Then a retest.
The format of the public 12-page sample at amansploit.com: an executive summary a non-technical reader can act on, then each finding with severity, impact, reproduction steps, evidence and a specific fix. A walkthrough call with your developers, and one retest of the fixes within 30 days, included.
what I need from you
Authorisation, an environment, accounts.
Every application is different. A 15-minute call to understand yours, then a written scope, price and timeline within two working days.
01
Written authorisation
A rules-of-engagement document — there's a free template at amansploit.com.
02
A test environment, or an agreed window on production
Either works; the scope says which.
03
Test accounts at each role
Access control can only be tested from every side of it.
04
Source code, if you want a white-box test
Which finds more.
what this is not
Not a certificate, not a scan with a logo on it.
It isn't a compliance certificate, and I'll never call it one. It isn't a red-team exercise or a network test of your office. It isn't an automated scan — you can run those yourself for free, and I'll tell you when that's all you need.
The scanner finds the shape of the surface. The test is the week spent in it by hand. Every request replayable, every fix retested.
before you ask for a quote
Questions people actually ask.
How much does a penetration test cost?+
Every application is different, so a test is scoped, not priced from a menu: a 15-minute call to understand the application, then a written scope, price and timeline within two working days.
What does the report look like?+
The same format as the public 12-page sample at amansploit.com: an executive summary a non-technical reader can act on, then each finding with severity, impact, reproduction steps, evidence and a specific fix.
Is a retest included?+
Yes. One retest of the fixes within 30 days of the report is included in every penetration test.
Is the testing manual or automated?+
Manual. Tooling is used to cover ground, not to generate the report, and every finding is reproduced by hand before it is written up.
Do I need to give you source code?+
Not necessarily. A white-box test with source access finds more; a grey-box test with test accounts at each role is also possible. The scope says which.
Is this a compliance certificate or a red-team exercise?+
Neither. It is a manual test of a web application and its API — not a certificate, not a red-team exercise, not a network test of your office.
get it scoped
Tell me what it is and who built it.
Written scope, price and timeline within two working days of the call.
