Review · $522 · 5 working days

Five working days. $522. A straight answer.

For a web application that's about to launch, about to raise, or about to be shown to a customer who'll ask hard questions. You don't need a full penetration test yet — you need someone who does this for a living to look properly and tell you the truth.

fixed price · fixed scope · one app, one environment

what's covered

One web application, one environment, with source access.

In five working days I check all of this — and the class of bug I find most often, in apps of every size, is the second one.

  1. 01

    Authentication and session handling

    Signup, login, reset, tokens, logout, what happens when they're wrong.

  2. 02

    Access control

    Whether user A can read or change user B's data by changing an ID, a role or a request.

  3. 03

    Input handling

    Injection, cross-site scripting, unsafe file handling.

  4. 04

    CORS and cross-origin configuration

    What another origin can read, send or trigger.

  5. 05

    Security headers, CSP, TLS and cookie flags

    This site is the reference; check it.

  6. 06

    Secrets

    In the codebase and across the full git history, not just the current commit.

  7. 07

    Dependencies with known vulnerabilities

    Audited and listed with what to do about each.

  8. 08

    Deployment and configuration basics

    Exposed admin surfaces, debug modes, default credentials, storage buckets.

what you get

Findings ranked by severity. If there are none, the document says so.

A written findings document, each with what it is, why it matters to your business, how to reproduce it, and how to fix it. A 30-minute walkthrough call.

If I find nothing that needs fixing, the document says so, and I won't invent findings to justify the fee or sell you a pentest you don't need.

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.

NW-02HIGHCVSS 3.1 7.7AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NFixed · retested

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.

price and timeline — fixed price, fixed scope

  • 522

    USD, fixed · ₹50,000 · one app, one environment

  • 5

    working days, from access to written findings

  • 8

    areas checked, listed above

  • 30 min

    walkthrough call with your developers

If the application is much larger than a single app in one environment, I'll tell you before starting, not after.

what it isn't

A review by one person in one week.

It isn't a full penetration test, and it won't find everything a two-week manual test finds. If your application is high-risk enough to need that, I'll tell you on day one — and if you book the test within 30 days, the $522 is credited against it.

It isn't a compliance certificate.

before you book

Questions people actually ask.

  • Is the review a compliance certificate?

    No. It is a written findings document from one experienced person in one week, ranked by severity with reproduction steps and fixes. It is not a certificate and I will never call it one.

  • How is a review different from a penetration test?

    A review is five working days on one application in one environment with source access, checking the eight areas listed on this page. A penetration test is a longer manual engagement with a wider scope and a report in the public sample format. If your application needs the test, I say so on day one, and the review fee is credited against it if you book within 30 days.

  • What do you need from me to start?

    Source access, one environment, test accounts at each role, and written authorisation. There is a free rules-of-engagement template at amansploit.com.

  • What if you find nothing?

    Then the document says so. I do not invent findings to justify the fee, and I do not sell you a penetration test you do not need.

  • What does it cost and how long does it take?

    $522 (₹50,000), fixed. Five working days from access to written findings, plus a 30-minute walkthrough call.

book a review

Ready to launch, or ready to find out?

Send the URL and a line about what it does. I reply within one working day.