Security
Security Baseline
A practical launch-readiness view of the site's current security posture, privacy boundaries, and OWASP-oriented follow-up items.
Current MVP Posture
County Freedom Index is currently a public county-level discovery website. It does not include user accounts, payments, private parcel applications, user-generated content, or a public write API. That keeps the MVP security surface smaller than an account-based app, but it still needs secure hosting, clear privacy terms, dependency maintenance, and conservative handling of public data claims.
Security Headers
The site is configured with a baseline set of browser security headers. These should be verified on the production domain after deployment.
- Strict-Transport-Security
- X-Content-Type-Options
- X-Frame-Options
- Cross-Origin-Opener-Policy
- Cross-Origin-Resource-Policy
- Referrer-Policy
- Permissions-Policy
- X-Permitted-Cross-Domain-Policies
- Origin-Agent-Cluster
- X-XSS-Protection
- Content-Security-Policy-Report-Only
Row Level Security Status
Row Level Security is not currently applicable because the MVP does not use a hosted application database with user-owned rows. The county dataset is stored in local JSON and generated files. If the project later adds Supabase, Postgres, user accounts, saved searches, paid tools, admin review queues, or user-submitted parcels, RLS should be enabled before launch for those tables.
OWASP-Oriented Review Notes
Access Control
The MVP is a public, static-style discovery site with no user accounts, payments, private dashboards, or writeable visitor data flows. Any future admin or user-data feature should add authentication, authorization checks, and row-level policies before launch.
Injection Risk
County pages are generated from local structured data and React rendering escapes text by default. Continue avoiding raw HTML injection and validate any future user-submitted input before storage or display.
Security Misconfiguration
The app ships security headers from the Next.js configuration, including HTTPS hardening, clickjacking protection, content-type protection, cross-origin boundaries, permissions limits, and a monitored Content Security Policy. Production deployment should keep HTTPS enforced and verify headers on the final domain.
Vulnerable Components
Dependency checks should be run before launch and during updates. Treat package upgrades, analytics scripts, map libraries, and future integrations as part of the security review surface.
Logging And Monitoring
Hosting logs, analytics, Search Console, and deployment monitoring should be used to spot broken routes, unusual traffic, errors, and crawl issues after launch.
Pre-Launch Security Checklist
- Run dependency and build checks before publishing major changes.
- Verify security headers on `https://countyfreedomindex.com` after deployment.
- Confirm no private local files, draft credentials, or non-public notes are linked from public routes.
- Keep analytics disclosure aligned with the Privacy Policy.
- Keep the Content Security Policy in report-only mode until production behavior is observed, then tighten carefully if analytics, maps, and images are stable.
- Add authentication, audit logs, and RLS before any admin database or user-submitted data feature.
Related Pages
Last updated: June 29, 2026