Architecture

Security architecture

The access model behind Godspeeds: role-based access control, protected routes, guarded API endpoints, and environment isolation.

Security is the reason this kit exists. AI-assisted development is very good at producing code that works and comparatively bad at producing code that is safe by default — missing authorization checks, endpoints that trust their input, and secrets that drift into client bundles. Godspeeds sets the defaults so those mistakes are harder to make.

Four layers

Route protection — middleware gates whole sections of the app before a request reaches a page.
Role-based access control — roles determine what a signed-in user can see and do, so authentication and authorization stay separate concerns.
Guarded API endpoints — every handler establishes who is calling before it does any work.
Environment isolation — development, preview, and production hold separate credentials and separate data.

Authorization is checked on the server

Hiding a button is not access control. A user who cannot see an admin link can still type the URL, and an endpoint that trusts a client-supplied user id can be called with somebody else's. Every protected route and every endpoint in Godspeeds re-establishes identity and role on the server.

When you add an endpoint, the authorization check is your responsibility. Copy the pattern from an existing protected handler rather than writing one from scratch.

Environment isolation

Use test keys locally and in preview deployments, and live keys only in production. Rotate any key that has ever been pasted into a chat window, a screenshot, or a commit. Keys are cheap to rotate and expensive to leak.

Before you launch

Every route that should require a session is covered by middleware.
Every API handler checks identity and role before touching data.
No secret is referenced from a client component.
Production uses its own credentials, separate from development.
Stripe webhook signatures are verified — see Payments.