Security

Security Baseline

A practical view of the site's current security posture, privacy boundaries, and OWASP-oriented follow-up items.

Current Security 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 public submission features. That keeps the current security surface smaller than an account-based app. It also depends on secure hosting, clear privacy terms, dependency maintenance, and conservative handling of public data claims.

The current launch surface is mostly static, generated from local JSON and source files for 3,143 county and county-equivalent profiles across 50 live state datasets. That scale makes route hygiene, source boundaries, sitemap controls, and deployment checks important even without user accounts.

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 site 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. Until then, the equivalent safeguard is to keep draft, reviewer-only, and guarded evidence out of public routes unless the launch and data-quality checks explicitly allow promotion.

Analytics And Tracking Boundary

The current site uses a conservative analytics posture. GA4 is configured through the production web stream, but it remains consent-gated and does not load until a visitor accepts optional analytics cookies. The current site does not use advertising cookies, remarketing pixels, affiliate tracking pixels, session replay, heatmaps, data broker integrations, advertising IDs, remarketing audiences, or cross-context behavioral advertising.

Any future analytics expansion, advertising pixel, affiliate tracking, lead-capture flow, saved-search feature, account system, paid tool, or third-party tag manager should go through a new privacy and security review before launch.

OWASP-Oriented Review Notes

Access Control

The current public site is a static-style discovery experience 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.

Data Integrity

County scores and source notes are generated from local structured data. Public score, verification, sitemap, and ranking changes should continue to move through guarded checks so draft or reviewer-only evidence is not promoted by accident.

Pre-Launch Security Checklist

Run the final local readiness bundle before the final owner Go/Hold decision.
Run the final Go gate only after final owner approval is recorded and the site's discovery-tool limits are acknowledged.
Run dependency, typecheck, build, and deploy-output checks before publishing major changes.
Run the live preannouncement gate before future sitemap resubmission, indexing requests, or public launch copy.
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 advertising cookies, remarketing pixels, affiliate tracking pixels, session replay, heatmaps, data broker integrations, advertising IDs, remarketing audiences, and cross-context behavioral advertising out of the public site unless a new privacy/security review approves them.
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.

Last updated: July 15, 2026