Security defaults

Every blamejs primitive ships with hostile-input handling, transport hardening, and audit emission already wired into the request lifecycle. Operators who do nothing get the same posture as operators who carefully read every config option.

Defaults are *not* opt-in. CSRF, origin verification, bot-guard, sealed storage, encrypted sessions, fetch-metadata enforcement, cookie prefixes (__Host- / __Secure-), DNS-over-HTTPS, and Trusted Types are wired into b.createApp() — not behind config flags an operator might forget to set.

Why defaults, not config? #

Frameworks that ship insecure defaults rely on operators reading docs, copying the right snippet, and never breaking that snippet during refactors. Real codebases drift. A bot-guard that ships disabled in the example app gets copied disabled into production.

blamejs inverts this: every defense ships ON, and the operator must explicitly disable each with an audited reason. The audit chain captures every disable so a future reviewer can see exactly what was loosened and why.

If a default trips a test, fix the test #

The temptation to disable a security default to make a test pass is the single largest source of long-term drift. blamejs's example apps and integration tests run with the production default chain enabled. When CSRF / origin / bot-guard / rate- limit blocks a fixture: send realistic browser headers (Origin, Sec-Fetch-Site, User-Agent) instead of disabling the middleware.

Strict CSP, no `unsafe-inline` #

The default Content-Security-Policy drops 'unsafe-inline' from style-src and script-src. Inline elements opt in via cspNonce; pages with no inline elements need no nonce at all. The default applies to every example app the framework ships.

Last updated 2026-08-08T16:39:49.652Z by seeder.