2026-10-22 · 6 min read

Sample MVP Security Review Report: Findings, Evidence and Fix Order

Northstar Notes — review summary

• ▸Example date: 21 October 2026
• ▸Review type: Free, fixed-scope MVP security review
• ▸Access supplied: Public staging URL, read-only repository and synthetic test accounts owned by the requester
• ▸Example result: Two high-priority findings and one medium-priority finding

Fix the cross-account data access and rotate the exposed key before inviting users. Correct the webhook verification before accepting real payments. Retest all three fixes before launch.

Scope and limits

This example examines the submitted web app and the repository areas supporting authentication, authorization, secrets, dependencies and the payment webhook. Testing uses only requester-authorized staging assets and synthetic data. No production writes, destructive tests, denial-of-service tests or access to real customer data are attempted.

This is a time-boxed engineering review, not a penetration test, compliance certification or guarantee that the app has no vulnerabilities. Areas not listed as checked are not assessed.

Findings

High — one signed-in user can read another user's notes

Evidence: Using synthetic account B, changing the note identifier in the staging request returned the synthetic note created by account A. The server route loaded a note by noteId but did not also restrict the query by the signed-in owner.

Why it matters: Any authenticated user who obtains or guesses another note identifier could read data belonging to that account.

Recommended fix: Enforce ownership in the server-side query or database policy, return a non-disclosing error for records outside the current account, and add an automated two-user test proving account B cannot read or change account A's records.

Retest: Repeat the authorized A/B request after the fix and confirm that account B receives no record and cannot update or delete it.

High — privileged database key is included in the client bundle

Evidence: A synthetic privileged-key marker placed in the example configuration was present in the built JavaScript served to an unauthenticated browser. The credential value is deliberately omitted.

Why it matters: A privileged server credential in browser-delivered code can bypass the access rules intended to protect user data.

Recommended fix: Revoke and rotate the exposed credential first, remove it from all client-side configuration, keep privileged operations on the server, and inspect repository history and deployment logs for earlier exposure. Do not paste the replacement key into a ticket or report.

Retest: Build from a clean checkout, search the emitted browser assets for the revoked and replacement markers, and verify that the client uses only a deliberately public credential constrained by server-side rules.

Medium — payment webhook accepts events without verifying the signature

Evidence: The example webhook handler parsed the request body and changed subscription state without first verifying the provider signature against the unmodified request body.

Why it matters: An unauthenticated sender could forge an event and trigger a state change that should follow only from the payment provider.

Recommended fix: Verify the signature using the provider's documented method before parsing or acting on the event, reject invalid or stale events, and make repeated delivery idempotent.

Retest: In an authorized test environment, confirm that a valid signed fixture is accepted, an altered body is rejected, and replaying the same event does not apply the change twice.

Fix order

1. Disable launch access if necessary, then rotate the exposed privileged key.
2. Enforce per-account authorization and add the two-user regression test.
3. Add webhook signature verification and idempotency before enabling real payments.
4. Retest the three findings and record the exact deployed revision.

If you want the same fixed-scope format applied to an app you own or are authorized to test, request a free MVP security review. Start with a public URL; any repository or platform access is optional and permission-based.