Web app security before launch: the smallest useful threat model

A threat model is a focused way to ask what could go wrong before a web app is trusted with real users, money, or sensitive information. It is not a security certification and it does not remove the need for specialist review where the risk requires it.

Start with assets and trust boundaries

List what must be protected: accounts, personal data, customer records, payments, administrative actions, secrets, and service availability. Then map where untrusted input enters, where identity is established, where external services receive data, and where an action changes a record or permission. This turns a generic security request into a review of actual system behavior.

Ask how each important path could be abused

• Can an unauthenticated person reach a protected action?
• Can one signed-in user read or change another tenant’s record?
• Is input validated on the server before it reaches business logic or storage?
• Could a failed request reveal unnecessary information or leave a partial state behind?
• Are high-risk actions rate-limited, logged appropriately, and recoverable?

Record controls and remaining risk

OWASP recommends applying syntactic and semantic validation to untrusted input, with server-side validation because client-side checks can be bypassed. Its HTTP header guidance also explains how response headers can mitigate classes of browser-side risk. Record the control, owner, test, and residual risk for each priority path rather than assuming a framework default resolves every concern.

Kiwi can include practical security considerations in a scoped MVP or launch build. Penetration testing, compliance conclusions, incident response, and high-risk security architecture require separately qualified specialists and scope.