Launch Knowledge Base
Identity, Security, and Trust Basics
A beginner-focused guide to authentication, authorization, sessions, cookies, tokens, HTTPS, least privilege, and the minimum security checks before launch.
Security for a first launch is not about knowing every advanced attack. It is about avoiding the common mistakes that expose users, data, credentials, or admin controls. Public software lives in an untrusted environment. Anyone can load the page, inspect browser code, call endpoints, submit unexpected input, and retry actions.
The minimum goal is simple: protect identities, protect credentials, protect private data, and fail closed when access is uncertain.
Authentication vs authorization
Authentication proves who the user is. Authorization decides what that user can do.
These are different checks. A logged-in user may be allowed to view one project but not another. A team member may be allowed to read logs but not change billing. An admin may be allowed to manage users but not access unrelated tenants.
Do not rely on UI visibility alone. Hiding a button does not protect the backend route. Every protected server operation should enforce authorization server-side.
Sessions, cookies, and tokens
Web apps commonly remember users through sessions, cookies, or tokens.
| Mechanism | Typical use | Launch concern |
|---|---|---|
| Session cookie | Browser login state | Secure, httpOnly, same-site, domain settings |
| Access token | API authorization | Expiration, storage, leakage risk |
| Refresh token | Long-lived renewal | High sensitivity and rotation |
| API key | Machine or integration access | Scope, storage, revocation |
Cookies used for sessions should be configured for production HTTPS. Server-readable session cookies should generally be httpOnly so browser JavaScript cannot read them. Tokens stored in browser-accessible places need careful threat modeling because cross-site scripting can expose them.
HTTPS everywhere
HTTPS protects traffic in transit and gives browsers a way to validate the server identity. It is also required for many modern web capabilities. Public login, admin, payment, account, and dashboard surfaces should not run over plain HTTP.
A site can have valid HTTPS on one hostname and not another. Test the exact production host. If both example.com and www.example.com are public, both need correct HTTPS and redirect behavior.
Least privilege
Least privilege means each user, service, token, and credential receives only the access it needs. A database user for one project should not be able to read every database. A worker token should not be able to manage billing. A public client key should not have server-admin permissions.
Apply least privilege to:
- user roles
- service accounts
- database users
- deploy tokens
- third-party API keys
- webhook credentials
- admin dashboards
This reduces damage when a credential leaks or a bug exposes an endpoint.
Input validation and safe errors
Any public endpoint receives untrusted input. Validate request bodies, query parameters, path parameters, file uploads, and webhook payloads. Reject invalid input before it reaches business logic.
Errors should help legitimate users recover without revealing secrets or internals. A response can say a request is invalid. It should not dump stack traces, database connection strings, private tokens, or full provider responses to the browser.
Logs can include more context than user-facing errors, but logs also need discipline. Do not log raw passwords, session cookies, tokens, private keys, or unnecessary personal data.
Admin and internal tools
Admin tools often become the weakest point because teams treat them as private even when they are reachable from the internet. If an admin route can be reached publicly, it needs authentication, authorization, audit visibility, and careful input validation.
For a first launch:
- require login for admin surfaces
- require an admin role for admin actions
- keep destructive actions explicit
- record who changed important settings
- avoid exposing raw secrets in the UI
Beginner security checklist
- Public app uses HTTPS.
- Login and logout work on the production domain.
- Protected routes reject anonymous users.
- Users cannot access another user's data by changing an id.
- Admin endpoints require admin authorization.
- Secrets are not committed to the repository.
- Secret values are not exposed in browser JavaScript.
- CORS allows expected production origins only.
- Webhooks verify signatures when supported.
- Production errors do not reveal stack traces to users.
- Logs avoid raw tokens and passwords.
Trust is also product experience
Users experience security through trust signals. Does the browser show HTTPS? Does login redirect cleanly? Does the product explain permission failures clearly? Does the app avoid asking for unnecessary access? Does the custom domain match the brand?
Security is not separate from launch quality. A confusing trust boundary can make a working product feel unsafe.
Flash Launch note
Flash Launch already separates control-plane access from public routes and treats signed user context, admin tokens, and project membership as explicit boundaries. That same product principle should be visible to users: identity, permissions, and production secrets deserve first-class setup, not hidden configuration fragments.