Frontend security review: pages a user should not see
A frontend security review checks pages, cookies, and uploads a signed-in user can reach. One app is $2,400 once, $1,200 to start, no subscription.
A frontend security review is the pass where I open what a signed-in user can open.
If the page renders for the wrong role, that is already a finding. You do not need a six-week red team to learn that a customer can see a staff export.
Short answer: A frontend security review covers routes, forms, uploads, downloads, cookies, and tokens on one application. I sell that inside a web application security review for $2,400 once, $1,200 to start. The report is due 48 hours after access works. You own the PDF. There is no subscription.
OWASP’s 2021 Top 10 ranks broken access control first. Their dataset says 94% of applications were tested for it, with an average incidence of 3.81% and more than 318,000 occurrences. That is coverage of the test, not “94% of apps are wide open.” It is still the class I expect to write about when a product has accounts.
What does a frontend security review actually check?
I walk the live UI as the roles you grant: every route that renders, every form that submits, every file that uploads or downloads, and what the cookie or token still allows after logout or a role change.
The table is the job. Price is for one application, one time.
| Check | In the $2,400 pass | Not in this pass |
|---|---|---|
| Routes a role can open, including ones the nav hides | Yes | A second product on another host |
| Cookies, tokens, logout, and back-button behavior | Yes | Admin rights inside your identity provider |
| Forms, uploads, exports, and downloads | Yes | A line-by-line source audit |
| APIs those pages already call | Yes, same engagement | A separate “API-only” invoice |
| One retest of the same URL within 14 days | Yes | Features you ship after that retest |
| Scanner PDF or a compliance certificate | No | I do not sell either |
Login itself — reset, invite, SSO mapping — is the sibling pass I describe in authentication security review. Same invoice. Different hour of the work.
Which pages should a signed-in user never reach?
If a customer can open a staff route, a billing export, or another tenant’s record by using the app the way it is built, that page is in scope. I treat a rendered screen as the finding.
I am not hunting hidden URLs from a wordlist as the main event. I start from the product:
- A member URL that still renders for a signed-out browser
- An admin screen linked in the HTML even when the menu hides it
- A download that ignores the role on the button
- An upload that accepts a file the role should never send
- A record that belongs to another organization and still opens
The last one is often enforced on the API, not in the React tree. I still reach it from the page. How I write that finding, without a recipe, is the point of the IDOR note.
Hidden nav is not a control. If the route answers, I treat it as reachable.
What should the cookie and the token do?
After logout, a role switch, or a session you meant to kill, the browser should stop being that user. If the account page still paints, the session failed. I record the path and the role, not the cookie value.
I look at behavior you can see, not a dump of your cookie flags for their own sake:
- Logout, then the back button or a refresh
- A token the page stores that still works after the user signs out
- A session that survives a password change you told me to expect
- Two roles in one browser, and whether the first role’s pages remain
I will not paste cookie values into the PDF. Evidence is the path, the role, and what rendered.
This is not an invoice chase and it is not a booking badge inside ChatGPT. Those are One Lane and Business MCP. A security review does not send your Friday report or take a Jobber job.
What is left out of the $2,400?
Source audit, a mobile binary, phishing, a second application, and any letter that exists only to satisfy a procurement stamp. The $2,400 price is one URL, once, with no monthly seat.
You are buying time on one URL. Frontend, auth, and the APIs the UI already calls. Numbers sit on pricing: $2,400 per app, $1,200 to start, the rest when the report is delivered. One free retest of that same URL inside 14 days.
Not included:
- Reading the repository as a separate engagement
- Your IdP tenant as an admin
- Unlimited hostnames because they share a brand
- Exploit steps an outsider could copy
- A CREST, PCI, or SOC letter I am not certified to sign
I do not invent certifications. If a customer contract requires a named stamp, hire the firm that holds it.
How does the pass run?
Trigger is written permission plus a user who can sign in. Action is the page walk. The system of record is the PDF. A human ships the fix, then I retest the same URL once.
- You authorize the URL, name prod or staging, and list what is out.
- I sign in as the role you granted and walk routes, forms, uploads, and downloads.
- I restore test data I created.
- You get severity, path, role, and a remediation an engineer can ticket.
- You fix. I retest that URL once, free, within 14 days.
The clock starts when login works, not when the card charges. A wide SaaS can land in a 24–72 hour window. Broken access is a pause, not a silent timer.
If you want the document shape before credentials, ask for the sample from the contact form.
When this isn’t the right move yet
Wait if there is no login, you cannot authorize the URL, or you need a compliance stamp instead of a ticket list. A marketing site and a half-built auth mock are too early. So is buying this when the real leak is invoices or a chat booking.
Wait if any of these are true.
- The site has no accounts. A marketing page does not need this pass.
- Login is still a mock. There is nothing to authorize.
- You cannot name a person who owns the URL.
- You need a compliance stamp, not a ticket list.
- You wanted someone to chase invoices or book jobs from a chat app. That is a different offer and a different page.
Buy it when one production or staging app has real users, you can grant a test account, and engineering will actually read a ranked list this week.
Start on the review page. $1,200 reserves the work. I confirm scope in writing. I do not book a call to explain the same offer.
FAQ
What is a frontend security review? +
It is an authorized pass over what a signed-in user can open: routes, forms, uploads, downloads, cookies, and tokens. I include that in the same $2,400 review as login and the APIs those pages already call. It is not a source read and not a scanner certificate.
Is the frontend included in the $2,400 price? +
Yes. One application is $2,400 once, with $1,200 to start and $1,200 when the report is delivered. Frontend, session, auth, and the APIs the UI already calls are one job. A second app is a second quote. There is no monthly fee.
Do you need two user roles? +
A second role makes the page checks sharper. I can still review a single role and write that limit in the note. I do not need admin on your identity provider. I need a user that can sign in on the URL you named.
Will the PDF include exploit steps? +
No. Findings name the route or action, the role, the severity, and a fix an engineer can ship. No payloads, no leftover credentials, and no client names. Ask for the redacted sample before you send access if you want the format first.
