Security Policy

1. Our Commitment

Security is not an afterthought at Haders — it is a core design constraint. We build and operate the platform with the assumption that it will be targeted, and we maintain controls accordingly. This Security Policy describes how we protect the Haders infrastructure, how we respond to vulnerabilities, and what we ask of researchers who discover issues.

2. Infrastructure Security

• Transport encryption.All traffic to Haders is encrypted in transit via TLS 1.2 or higher. HTTPS is enforced across all subdomains. Plaintext HTTP connections are rejected or redirected.
• At-rest encryption.The database and all persistent storage volumes are encrypted at rest. Encryption keys are managed separately from data.
• Network perimeter.All public traffic passes through Cloudflare before reaching our origin servers. This provides DDoS mitigation, WAF filtering, and IP reputation scoring at the edge.
• Origin protection.The origin server IP is not publicly exposed. Direct connections that bypass Cloudflare are dropped at the firewall level.
• Firewall rules.Only ports 80 and 443 are open on the origin. All other inbound ports are blocked. Outbound egress is restricted to required services.
• Admin access.The admin panel (admin.haders.site) is restricted by IP allowlist. Administrative operations require both authentication and an allowed source IP.
• SSH access.Direct SSH access to production infrastructure is restricted to authorised keys only. Password authentication is disabled.

3. Application Security

• Authentication.Passwords are hashed with bcrypt at 12 rounds. Session tokens are cryptographically signed (HMAC) and are httpOnly, Secure, and SameSite=Lax. Sessions expire after 30 days.
• OTP verification.New logins from unrecognised devices trigger a 6-digit OTP sent to the account email. OTPs expire after 10 minutes and are single-use.
• Rate limiting.All endpoints are rate-limited at the nginx layer using per-IP token bucket limits. Auth endpoints use the tightest limits. Limits key on the real client IP via Cloudflare CF-Connecting-IP, not the edge IP.
• Input validation.All API inputs are validated and sanitised server-side. SQL injection is not possible — the database layer uses parameterised queries exclusively.
• Content Security Policy.All pages serve strict Content-Security-Policy headers. Inline scripts are restricted. External script sources are allowlisted to known CDNs only.
• Security headers.All responses include X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy, Permissions-Policy, and Cross-Origin-Opener-Policy headers.
• Dependency management.Dependencies are audited regularly with npm audit. Critical and high severity advisories are patched within 48 hours of disclosure.
• Secrets management.Secrets are stored in environment variables, never in source code or version control. The repository is private and access-controlled.

4. Data Isolation

• Per-user data.Conversations, memory, and agents are scoped strictly to the authenticated user. There is no mechanism by which one user can access another user's data through normal platform use.
• Admin scope.Admin accounts can view aggregate platform data and user metadata for moderation purposes. Admins cannot access conversation content without explicit owner authorisation.
• AI inference.Conversation content is passed to inference endpoints to generate responses. Inference providers are contractually required to not retain request data beyond the duration of a single inference call.
• Logging.Application logs do not contain conversation content. Logs capture only metadata (timestamps, endpoint, status code, user ID) sufficient for debugging and abuse detection.

5. Incident Response

We operate a defined incident response process for security events:

• Detection.Automated alerting fires on anomalous patterns — unusual login geography, high error rates, unexpected admin access, and traffic spikes.
• Triage.On-call staff triage alerts within 1 hour during business hours and within 4 hours outside business hours.
• Containment.Affected accounts, IPs, or services are isolated immediately upon confirmed incident. Cloudflare firewall rules can be updated within minutes.
• User notification.Affected users are notified by email within 72 hours of a confirmed breach that affects their data, in line with applicable data protection obligations.
• Post-incident review.Every confirmed incident results in a written post-mortem reviewing root cause, timeline, and control improvements.

6. Vulnerability Disclosure

We welcome responsible disclosure from security researchers. If you discover a vulnerability in the Haders platform, please report it to us before public disclosure. Email: security@haders.site Please include in your report: • A clear description of the vulnerability • Steps to reproduce • Your assessment of impact and exploitability • Any proof-of-concept (non-destructive only) We ask that you: • Give us reasonable time to investigate and patch before disclosing publicly (we target 30 days for critical issues) • Avoid accessing, modifying, or deleting data that is not your own • Do not perform denial-of-service testing against production infrastructure • Do not use automated scanners against the platform without prior agreement We do not currently operate a paid bug bounty programme, but we will publicly acknowledge reporters by name or handle (with their consent) for valid findings.

7. Out of Scope

The following are explicitly out of scope for vulnerability reports:

• Social engineering.Attacks targeting Haders staff rather than technical controls.
• Physical attacks.Physical access to infrastructure or data centres.
• Third-party services.Vulnerabilities in Cloudflare, Stripe, Resend, or RunPod — report these directly to those vendors.
• Rate limit bypasses via proxies.Using rotating proxies or botnets to bypass rate limits — this is prohibited use, not a vulnerability.
• Self-XSS.XSS that requires the attacker to inject into their own browser session only.
• Theoretical attacks.Reports without a working proof of concept or clear reproduction path.

8. Safe Harbour

We will not pursue legal action against researchers who discover and responsibly disclose vulnerabilities in accordance with this policy. We consider good-faith security research conducted under this policy to be authorised under our Terms of Service. This safe harbour does not extend to destructive testing, exfiltration of real user data, or testing against accounts you do not own.

9. Contact

Security issues: security@haders.site General enquiries: support@haders.site Discord: discord.gg/X8sdEVHchA PGP key available on request for encrypted disclosures.