Staging vs production security review: pick one URL
A staging vs production security review is $2,400 once for one URL, no subscription. Test the host customers use, or staging only if that build matches.
A staging vs production security review is the choice of which URL goes in the authorization. I review one web app for $2,400 once, $1,200 to start, and the report is due 48 hours after that URL’s login works. Founders and engineering leads use this when a customer, a questionnaire, or a launch is asking whether the app was actually looked at.
Short answer: A staging vs production security review means I test one URL you name, for $2,400 once and $1,200 to start. Pick production when customers already use it and I can stay inside a test account. Pick staging when that build is the release you are about to ship. A clean staging PDF does not cover production. There is no subscription.
What is a staging vs production security review?
It is one authorized pass on one URL you name as staging or production. The price does not change. A clean result on staging does not cover the host your customers use, and a production login does not authorize the other environment.
Frontend, session, auth, and the APIs the UI already calls are the same job on either side. Source code, a mobile binary, and a second product are not. The offer is the web application security review. Numbers also sit on pricing.
| Decision | Staging URL | Production URL |
|---|---|---|
| What the PDF covers | That host and that build | The host customers hit |
| Data | Test or copied records you approve | Live records behind the test user |
| Drift | High if staging lags the release | Config that exists only live is in play |
| Customer side effects | Usually none | Writes, mail, and logs can be real |
| Price | $2,400 once, one URL | Same $2,400, not a surcharge |
| The other environment | A second quote | A second quote |
Invoice chase is a different purchase. That is One Lane at $3,500 for one named ops job, not a pass on your app.
Which host should the scope name?
Name production when real users are on it and you can hand me a test account plus a written ban on deletes, mass mail, and charges. Name staging when that build is the release you will ship, and you will not treat the PDF as proof about production.
The OWASP Web Security Testing Guide treats user acceptance as the closest stand-in for the release configuration, except the data: test records stand in for real ones. Certificates, debug routes, and admin pages still drift after the last deploy.
“The app” is not a URL. Both hosts means two reviews. I will not wander from one to the other because a login happened to work.
What does a staging pass fail to prove?
It fails to prove the host customers use. It proves the build I could sign into. If staging is a week behind, missing the live certificate, or still serving a debug error page production already removed, the findings will not match.
Common misses I see when someone sends the quiet host:
- A header or cookie flag set on staging and dropped by the production proxy.
- An admin route left on production after staging was cleaned.
- Object access that only fails when the ID belongs to another live tenant.
- Mail and webhooks that staging stubs out, or a control that exists on only one host.
OWASP’s platform tests also flag log-filling checks as dangerous on production. I do not run those. Naming the host keeps those checks off and the real config in.
A staging pass is the right buy the week before a release, if engineering will read it before the deploy. It is the wrong PDF for a customer who asked about the live app.
How do you test production without hitting customers?
You grant one test user, you write what I must not do, and I stop when a check would email a person, change a live invoice, or only works by touching the other environment.
Workflow, in order:
- Trigger. Written permission from someone who controls the host, plus the URL labeled production or staging.
- Action. I sign in as that user and walk the pages, the session, and the APIs those pages already call. A second role is in only if you grant it.
- System of record. The PDF: ranked findings, a fix an engineer can ship, test state restored. No exploit payloads. No customer names. A sample pentest report shows the shape before you send credentials.
- Human escalation. If the next step would mail a customer, delete a record, or requires the other host, I stop and ask. You patch. I retest that same URL once, free, within 14 days.
Production rules I expect in the note:
- No password resets against real inboxes.
- No charges, refunds, or payout calls.
- No exports of a full customer table.
- Restore any record the test user created.
- Neighbor tenants, the vendor behind SSO, and the other environment are out.
That permission note is the same bar as an authorized web app review. Staging does not skip it. Production does not add a surcharge for having it.
What stays out of the $2,400 either way?
Source audit, a mobile binary, phishing, a scanner certificate, a compliance letter, and any second URL. The $2,400 price is one host, once. You own the PDF. There is no monthly seat.
A tight app can finish in 24 hours. A wide one can take up to 72. The promise is 48 hours after access works, not after the card charge. Broken SSO does not burn the clock.
I do not hold offensive-security certifications, and I will not invent any. If a questionnaire demands a multi-week certified program, this pass will not satisfy the letter.
When this isn’t the right move yet
Wait if you cannot name one URL, cannot grant a login this week, or plan to treat a stale staging report as proof about production. Those three gaps burn the $1,200 start on a host you will argue about after the PDF lands.
Do not buy yet when:
- Staging last matched production a month ago and a customer is asking about the live app.
- You want both environments on one invoice.
- Nobody on your side can authorize the host in writing.
- Engineering will not read a ranked list this week.
- You need a source review, a mobile binary, or a stamp I do not sell.
- The only account you can share is a real customer’s password.
Fix the host choice first. Then pay.
What do you send before I start?
One URL, the word staging or production, a test user that can sign in on that host, and a short list of what is out. I confirm that note before the clock runs. A screenshot of the other environment is not access.
Checklist:
- The exact host, including which environment.
- Written authorization from the owner of that system.
- A working test login on that host, not a screenshot of the other one.
- Out of scope: the other environment, neighbor tenants, vendors you do not control.
- The side-effect rules: no customer mail, no deletes, no live charges.
- The name of the person who will read the PDF this week.
Start on the review form. $1,200 reserves the work. I confirm the host, the roles, and what is out before the clock runs. Want the document shape first? Ask for the sample. I reply on the form. I do not book a call.
FAQ
Should I test staging or production? +
Test the URL customers open this week when you can grant a test account and ban destructive writes. Use staging only when that build is the release you are about to ship, and say so in writing. A clean staging report does not cover production. The price is the same either way.
Does a staging review cost less? +
No. A staging vs production security review is $2,400 once for one URL: $1,200 to start and $1,200 when the report is delivered. Staging is not a discount. Production is not a surcharge. The other environment is a second quote. There is no subscription.
Will you touch live customer data? +
I use the account you grant. On production I stay inside that user, skip destructive writes, and restore test state. The PDF does not name your customers and does not include exploit payloads. If a check would email a real person or change a live record, I stop and ask.
When does the 48-hour clock start? +
After written scope and a working login on the URL in the note. Paying the $1,200 start does not start it. A staging login does not start a production review. One free retest of that same URL is included within 14 days of the report.
