Application security
What protects a kreogen application, and what you add per project.
kreogen ships the protections that make sense for every project and leaves the rest to be chosen deliberately.
What ships
Security headers and CSP. Nosecone sets the standard header set, and the Content Security Policy is enforced rather than merely present — see headers.
Rate limiting. Redis-backed, applied to the surfaces that need it. See rate limiting.
Auth. Sessions are HTTP-only, signed cookies with a server-side store. Every protected route verifies against the database; the middleware check is an optimistic short-circuit, not the authorisation decision.
Input validation. Zod at every boundary — environment variables, form input, webhook payloads.
Secret hygiene. Secrets never reach the client: server-only enforces the
boundary at build time, and GitLab secret detection runs on every pipeline.
Dependency updates. Renovate opens grouped update MRs weekly and automerges safe ones.
What is deliberately not included
There is no managed bot detection or WAF. Those need a vendor account and a network hop on every request, and the right answer varies per project — a marketing site and an internal tool have very different threat models.
If a project needs it, add it at the edge in front of the app rather than in application middleware.
Per-project decisions
Authorisation. Better Auth provides organizations and roles; what each role may do is application logic. Enforce it server-side, in the query.
Multi-tenancy. Scope every query by orgId. A missing filter is the most
common serious bug in a multi-tenant application, and no framework will catch
it for you.
Audit logging. The structured logger is the right place to start.
Data retention. Depends on the client's obligations.
Reporting
Vulnerabilities in the template go to security@kreotic.dev — see SECURITY.md.