Hardening
Configuration-level security — headers, TLS, cookies, CSP and the settings that decay.
Security → Hardening checks configuration rather than versions.
What is checked
| Area | |
|---|---|
| Security headers | HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy |
| TLS | Version, cipher suites, certificate expiry |
| Cookies | Secure, HttpOnly, SameSite |
| CORS | Which origins are allowed |
| Redirects | HTTP to HTTPS |
CSP reporting
AccelerUp accepts CSP violation reports at
POST /api/v1/security/csp-report — public and unauthenticated, because
browsers post there without credentials.
Deploy a CSP in report-only mode first and read the reports for a couple of weeks. An enforced CSP that blocks something legitimate breaks the page for the users who hit it, and does so silently from your side.
Certificate expiry
Tracked, with an alert well before it happens.
Certificate expiry is the most preventable outage there is: completely predictable, entirely avoidable, and still a regular cause of downtime because the renewal automation failed quietly three weeks earlier.
Alert at 30, 14 and 7 days. Automation that has broken will have broken by the first one.
AccelerUp's own hardening
The platform enforces its own: security headers, HttpOnly session cookies,
2FA enforcement, account lockout, IP allowlisting, rate limits, and a strict
proxy-trust model.
See Environment variables for what is configurable,
and note TRUSTED_PROXY_CIDRS in particular — without it, rate limits and audit
logs both record the proxy rather than the client.
Related
Where this behaviour lives: frontend/src/app/security-hardening/, backend/internal/handler/security_hardening_handler.go. If the code and this page disagree, the code is right — please fix the page.
Part of Security — Vulnerabilities, compliance, hardening and enterprise identity.