Pre-launch security review
What a security review looks like
The findings section of a pre-launch security review, answering the question the client actually asked: is this safe to put a competitor's data into? Three findings from a multi-tenant SaaS on Node.js, PostgreSQL and AWS. The P0 is a composite chain rather than a list of separate weaknesses — a token claim never re-checked against current membership, row-level security enabled on 3 of 19 tenant-scoped tables, and an application role that owns those tables and is therefore exempt from the policies on them. The subject is fictional and every finding invented; external claims are cited to PostgreSQL, OWASP and AWS documentation.
PostgreSQL · Row-level security · Multi-tenant SaaS
-
Classification, with its reason
Every finding says why it is a P0 and not a P1, in the document's own words. A severity with no argument behind it is a preference, and you cannot check a preference.
-
A chain, not a list
The P0 is written as one path rather than four separate weaknesses: a token is minted, membership changes, the old scope keeps being served, and the database applies no independent check. The consequence is stated plainly — revoking access does not revoke access for up to 24 hours.
-
What the review could not establish
An assessment basis stated up front: read-only access to configuration and code, no penetration testing, no live traffic. Whether any of it has been exploited is named as a question this review cannot answer.
What a security review looks like
Fictional sample · 3 pages