Tenant-aware access
Customer users can manage their own sites and add additional sites under their account, while sites owned by other accounts remain hidden and unavailable.
Security posture · Public summary
Security measures built around tenant isolation and a safe public snippet.
Lean Cookie Consent is designed to give customers a hosted consent layer without exposing admin capabilities on their websites. This page summarizes the main controls applied across the platform, snippet, APIs, release process and production infrastructure.
Application controls
Access boundaries are enforced server-side, not only through menu visibility or client-side navigation.
Role separation
Founder-only areas such as global operational views, mission control and backup controls are separated from Pro-user workspaces.
CSRF protection
Sensitive form submissions across login, registration, reset, admin and client pages are protected by a central CSRF guard.
Session safety
Sensitive pages use no-store cache headers, HTTPS enforcement in production and hardened password reset behavior.
Abuse limits
Rate limits protect registration, site creation, beta invitations, password reset and account-related flows from automated abuse.
Security tests
A dedicated security matrix verifies owner versus Pro-user behavior, assigned-site versus foreign-site access and protected endpoint behavior.
Public snippet and API hardening
The snippet is meant to run on customer websites, so it has to be lightweight and tightly scoped.
Per-site keys
Each website uses a distinct site key, domain profile, policy version and consent evidence trail.
Safe DOM insertion
Configurable colors, font values and policy URLs are validated before being inserted into the page.
Script release controls
When scripts are released after consent, only allowlisted safe attributes are copied. Inline handlers and unsafe URL schemes are not copied.
Origin enforcement
Consent API requests are bound to the configured website domain through Origin and CORS checks.
Scanner guardrails
Scanner URL handling blocks private ranges, localhost, unsupported schemes and unsafe redirects.
Bounded tracking input
Acquisition and visit tracking accepts only bounded, sanitized fields rather than arbitrary payloads.
Data and release hygiene
Consent evidence should be useful for operations without leaking unnecessary secrets or sensitive runtime material.
Consent evidence
Records include choices, policy version, banner version, domain and timestamp. Technical identifiers are pseudonymized where supported.
Safer exports
CSV exports are protected against spreadsheet formula injection, and downloadable backups are redacted.
Secret-free packages
Production packages exclude runtime secrets, generated passwords, databases, logs, backups, tests and local scripts.
Private runtime data
The production document root points to public runtime files while private configuration and data stay outside public web exposure.
Browser headers
Security headers include content-type protection, referrer policy, permissions policy, HSTS on HTTPS, CSP and framing restrictions where applicable.
Retention cleanup
Expired reset records, rate-limit records and operational logs are cleaned through retention routines.
Infrastructure posture
Production access and network exposure are intentionally narrow. The public website and app are checked after deploys and reboots for service health, TLS readiness, firewall posture and security headers.
✓
Key-based operational SSH access.
✓
Root and password SSH login disabled.
✓
Firewall limited to required public services.
✓
Valid TLS certificates for active Lean Cookie Consent domains.
Ongoing hardening
Security is not treated as finished. Current next steps are periodic checks, external baseline scans after major releases, restore testing and broader business-logic abuse testing.
This page is a public summary. It intentionally avoids operational secrets, private paths, credentials, exact server access details and other information that should not be published.