Illustrative deliverable · not a client case study

Production Risk Review

Sample application: Northstar Projects

report_id: PRR-SAMPLE-001

review_type: repository + configuration

status: delivered

This report uses a fictional application and representative findings to show the delivered format. It does not describe a client, claim a completed engagement, or establish that another application has the same risks.

01 · Executive summary

Do not open paid onboarding yet.

The reviewed application has two launch-blocking issues: billing events are trusted without signature verification, and a project lookup does not enforce tenant ownership. Together, these permit unpaid entitlement upgrades and cross-customer data access. The remaining high and medium findings should be fixed in the same release but do not independently require delaying a private, non-paying pilot.

critical findings

high findings

medium findings

low findings

Launch blockers

— Verify Stripe webhook signatures and prevent replay
— Enforce tenant identity on every project operation

Controls observed

— Secrets are not committed to the repository
— Session cookies use Secure, HttpOnly, and SameSite
— Database migrations have a staging path

02 · Scope and limitations

Evidence reviewed

Included

— Application repository at commit abc123
— Infrastructure and environment configuration export
— Auth, billing, API, and database access paths
— Automated tests and deployment workflow
— 30-minute architecture context call

Not included

— Penetration testing or active exploitation
— Production customer data
— SOC 2, ISO 27001, or compliance certification
— Third-party source code not present in the repository
— Availability or load testing

03 · Prioritized findings

Evidence, impact, fix, verification.

PRR-001 · Billing + webhooks

Subscription tier can be upgraded with a forged webhook

critical

Evidence

The billing handler parses request JSON and applies invoice.paid without verifying the Stripe-Signature header against the raw request body.

Business impact

An unauthenticated caller can submit a fabricated paid event and grant an account Pro access without completing payment.

Recommended fix

Verify every event with Stripe.webhooks.constructEvent(), reject missing or invalid signatures, and make event processing idempotent on the Stripe event ID.

Verification

Integration tests must reject missing/invalid signatures and prove a replayed valid event changes entitlement only once.

PRR-002 · Tenant isolation

Project lookup is missing the tenant boundary

critical

Evidence

GET /api/projects/:id selects by project ID and checks only that a valid session exists. The query does not include tenant_id and performs no ownership check after retrieval.

Business impact

An authenticated customer who obtains another project ID can read project metadata belonging to a different account.

Recommended fix

Resolve tenant identity from the server-side session and require both project ID and tenant ID in the query. Return 404 for cross-tenant IDs.

Verification

Create two tenants in an integration test and prove tenant A cannot read, update, or delete tenant B’s project IDs.

PRR-003 · Auth + sessions

Admin capability is enforced only in the interface

high

Evidence

The settings page hides the export button for non-admins, but POST /api/export checks authentication without verifying the admin role.

Business impact

Any signed-in user can call the endpoint directly and export data intended for workspace administrators.

Recommended fix

Add a server-side permission check before export job creation and record the acting user, workspace, and decision in the audit log.

Verification

API tests should return 403 for a member and 202 for an admin using otherwise identical requests.

PRR-004 · Logging + errors

Production errors can expose provider responses

medium

Evidence

Unhandled upstream failures serialize err.message into the public API response. Provider messages may include request fragments and internal identifiers.

Business impact

Customers and automated probes receive internal implementation details that make further attacks easier and may expose submitted content.

Recommended fix

Return stable public error codes, keep detailed context in structured server logs, and redact tokens, cookies, authorization headers, and request bodies.

Verification

Force provider failures in tests and snapshot the public response and redacted log record separately.

04 · Remediation sequence

The shortest safe path to launch.

Order	Work	Estimate	Launch gate
01	Stripe signature verification + replay test	0.5–1 day	Required
02	Tenant-scoped data access helper + isolation tests	1–2 days	Required
03	Server-side admin authorization	0.5 day	Before broad beta
04	Public error envelope + log redaction	0.5–1 day	Before broad beta

Estimate ranges are planning guidance, not a fixed implementation quote. A Hardening Sprint scope is based on validated findings and repository conditions.

Want this review for your application?

Fixed scope. $495. Delivered in three business days after access is ready.

Get a production review →