HerdOS Security Hardening

Purpose
- Protect each client farm from other clients.
- Protect the platform from external attacks, internal misuse, and accidental or planted code changes.
- Keep secrets, operating credentials, and cloud details out of public app files.

Built-in controls in this package
- Farm isolation: all operational records are keyed by organization ID.
- Field app linking: each downloaded Field app carries only the selected farm identity and keeps its local queue independent.
- API tenant guard: authenticated token organization IDs cannot be overridden by request headers.
- PostgreSQL RLS: the included schema forces organization_id rules at the database layer.
- Security headers: API responses include nosniff, frame denial, referrer protection, same-origin resource policy, and JSON-only CSP.
- Browser CSP: main and Field pages only load same-origin scripts and block plugin/object injection.
- Rate limiting: auth, password reset, admin, sync, and general API requests are throttled.
- Integrity checks: HERDOS-SECURITY-CHECKSUMS.json lists trusted file hashes; herdos-security-guard.js warns when critical app files do not match.
- Offline safety: Field and main offline queues stay organization-scoped and device-scoped.
- Audit trails: security actions, sync batches, field devices, and work records carry timestamps and organization context.
- Security decision register: HERDOS-SECURITY-DECISIONS.txt separates useful controls from controls that would harm field usability.
- MacBook owner workstation checklist: HERDOS-MACBOOK-PRO-SECURITY.txt keeps development-machine security separate from customer runtime behavior.

Production requirements before accepting real customers
- Run the API with HERDOS_REQUIRE_AUTH=true and HERDOS_REQUIRE_TENANT=true.
- Use a managed auth provider with MFA, password reset, device/session controls, and strong password policy.
- Use HTTPS everywhere. Keep HERDOS_ENFORCE_HTTPS=true in production.
- Set HERDOS_CORS_ORIGIN to the exact app domain, not a wildcard.
- Keep .env files private. Do not upload .env to public hosting, email it, or include it in public packages.
- Use managed PostgreSQL/Supabase/AWS RDS with RLS enabled and tested.
- Run production with HERDOS_STORAGE_ADAPTER=postgres, HERDOS_ALLOW_JSON_STORE=false, and DATABASE_URL stored only as a server-side secret.
- Use a database role without BYPASSRLS for normal API traffic. Supabase service-role credentials and database superuser credentials must never be placed in frontend, mobile, or downloadable files.
- Give each worker the least role needed for the job. Owners/admins should be the only users able to manage users, finances, deletion, and security.
- Keep backups enabled and run restore drills on a test database.
- Review crash reports, rate-limit events, failed logins, and integrity warnings.
- Rebuild HERDOS-SECURITY-CHECKSUMS.json after approved code changes with node tools/herdos-security-check.js --write, then distribute only the rebuilt package.
- Apply HERDOS-SECURITY-HEADERS.example, or equivalent hosting rules, on the production domain.
- Use HERDOS-SECURITY-DECISIONS.txt before adding obfuscation, device binding, anti-debugging, or code-signing changes so the security layer does not interrupt normal farm work.

Operational rule
- If HerdOS displays a file-integrity warning, stop using that copy immediately. Reinstall from the trusted package or trusted domain, rotate exposed credentials, and review recent sync/audit activity.
