# Pre-launch security testing for web apps and APIs

Source: https://penetrationtestservices.com/pre-launch-security-testing/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

Pre launch security testing for a web app or API: the seven areas to test first, how to set up staging, and what the pentest report should give your team.

> **Short answer:** Pre-launch security testing is a penetration test of a web app or API before real users and data arrive. Test a build that is close to final, in a staging environment that matches production. Start with authentication, access control and anything that handles money or personal data. Fix, then retest, before launch.

Once real users arrive, a flaw costs more to fix and can expose real data. A pre-launch penetration test finds the serious problems while you can still change the plan.

## What should we test first?

Test the places where one mistake has the largest effect. [OWASP Top 10:2025](https://owasp.org/www-project-top-ten/) puts Broken Access Control first, so start there.

| Priority | Area | Issue it finds |
|---|---|---|
| 1 | Access control | User A can read or change user B's data by changing an ID |
| 2 | Authentication and sessions | Weak reset flows, tokens that never expire, MFA bypass |
| 3 | Payments and entitlements | A user reaches paid features, or changes a price or quantity |
| 4 | Personal and sensitive data | Fields in API responses that the screen never shows |
| 5 | File upload and import | Unsafe file types, files served to the wrong user |
| 6 | Secrets and client code | Keys, tokens and hidden routes in JavaScript bundles |
| 7 | Rate limits | Unbounded sign-up, login or email sending |

The [web application](/web-application-penetration-testing/) and [API](/api-penetration-testing/) pages cover each area in more detail.

## How should we set up staging?

Make staging match production: same code, same auth settings, same API gateway rules. Load it with test data that looks real but is not. Give us test accounts for each role, in two separate users or tenants. Turn off real email and payment sending, or point them at sandboxes. Tell us about any WAF or rate limit so we can plan around it.

Freeze the build we test. Give us the version or commit tag. Our guide on [how to prepare for a penetration test](/guides/how-to-prepare-for-a-penetration-test/) lists freeze windows, allowlists and contacts.

## How do we prove findings before launch?

A finding needs evidence of a real effect. We prove a write by reading the record back through another session. We run controls beside every exploit request: nonexistent IDs, wrong record types, another account's token and anonymous calls. The report lists the controls that held, so you know what to keep when you change code.

> **Sample finding:** This is a demonstration. It uses a fictional app, Harbor Notes, and no real customer system was tested.
> 
> **Finding L-01: A client bundle exposes an admin route (Medium).** Review of `main.4f2a.js` on staging showed a path the interface never links.
> 
> ```http
> GET /api/admin/users?limit=5 HTTP/1.1
> Host: staging.example.com
> Cookie: session=
> ```
> 
> ```http
> HTTP/1.1 200 OK
> {"users":[{"email":"a@example.com","role":"user"}, ...]}
> ```
> 
> Observed with a normal user session. The same call without a session returned 401, which held. Fix: require the admin role on the server for every `/api/admin` route.
## What do you get?

You get a report in HTML, PDF and Markdown, with proof-of-concept scripts. It contains an executive summary with priority actions, a findings table, and one section per finding with impact, reproduction and remediation. After your fixes, we can retest (see [retesting](/retesting/)). If you built the product on a no-code platform or with AI coding tools, read about [no-code app security testing](/no-code-app-security-testing/).

## What do we need from you?

- Written authorization from the system owner.
- A staging URL and the build or tag to test.
- Test accounts for each role, in at least two users or tenants.
- Docs, an API collection or a route list.
- Details of integrations and what we must not touch.
- A technical contact, and your planned launch date so we can discuss fix time.

## What changes the quote?

Scope sets the price: features, roles, API routes, integrations and how close staging is to production. A retest adds work. We publish no prices (see [pricing](/pricing/)).

Early-stage and want to try us? Ask about the [free pentest pilot](/free-pentest/). Otherwise [request a pentest](/contact/).

## Questions

### How late can we test before launch?

Leave time to fix and retest. A test the day before launch finds problems you cannot fix in time. Test a build that is feature-complete, then freeze changes to the areas we test. Plan a fix window after the report.

### Can we test on staging instead of production?

Yes, and for pre-launch work it is the best choice. Staging must match production in code, configuration and auth. If staging differs, tell us what differs. Findings that depend on production-only settings need a short check there.

### What if the app is still changing?

Agree a build or release tag to test. We test that version and report against it. Later changes are out of scope until a new test or retest. Large late changes are why teams schedule a second, smaller test.

### Do we need a full test, or can we start smaller?

You can start with the highest-risk areas: sign-in, access control, payments and file handling. A narrow scope costs less and gets answers sooner. Say what you will not test, so the report states it.

## Sources

- [OWASP Top 10:2025](https://owasp.org/www-project-top-ten/)
- [OWASP Web Security Testing Guide](https://wstg.owasp.org/)