# Security Policy

_Last updated: v6.0.0_

This document describes the security measures built into the Bulk Email
SaaS Platform, and how to report a security issue.

## Authentication & Access Control

- Passwords are hashed with PHP's `password_hash()` (bcrypt) — never
  stored or logged in plain text.
- **Login rate-limiting**: an account is temporarily locked after 5
  failed login attempts within 15 minutes (tracked by both account and
  IP address, so both a targeted attack on one account and a
  spray-across-accounts attack from one source are caught).
- **CAPTCHA**: a security check appears after repeated failed login
  attempts, and on every password-reset request, to slow down automated
  credential-stuffing and email-bombing attempts.
- **Two-factor authentication (2FA/TOTP)**: available to every user as
  an opt-in security upgrade, and **mandatory for Super Admin accounts**
  (enforced at first login after upgrade — a Super Admin cannot access
  the platform without completing 2FA setup). Compatible with any
  standard TOTP authenticator app (Google Authenticator, Authy,
  1Password, etc.).
- **Session security**: session cookies are marked `HttpOnly` (not
  readable by JavaScript, mitigating XSS-based session theft),
  `SameSite=Lax` (CSRF defense-in-depth), and `Secure` when served over
  HTTPS. Session IDs are regenerated on every login and 2FA verification
  to prevent session fixation.
- **CSRF protection**: every state-changing form submission requires a
  per-session CSRF token, verified server-side.

## Data Protection

- **Per-company encryption isolation**: each company's SMTP credentials
  and DKIM signing keys are encrypted with a key derived specifically
  for that company (via HKDF from the platform's master key), so no two
  companies' secrets share the exact same encryption key.
- **Multi-tenant data isolation**: every company's contacts, groups,
  templates, campaigns, and settings are strictly scoped and cannot be
  accessed by another company's users.
- **Encryption in transit**: SMTP connections use TLS/SSL; the
  application itself should always be deployed behind HTTPS (see
  deployment notes in `README.md`).
- **Security response headers**: Content-Security-Policy,
  X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and
  Strict-Transport-Security (on HTTPS) are set on every response.

## Auditing

- Every account creation, settings change, campaign send, contact
  deletion, and similar action is recorded in the Activity Log, along
  with who performed it and when.
- Sensitive **read** access is also logged, not just changes — viewing
  SMTP settings, viewing/generating DKIM keys, exporting contact data,
  and a Super Admin accessing a specific company's details all leave an
  audit trail.
- Super Admins can review activity across all companies; Company Admins
  can review activity within their own company.

## Reporting a Security Issue

If you discover a security vulnerability in this platform, please
report it privately rather than opening a public issue — email the
address configured in **Super Admin → Platform Settings → Platform
Notification Email** for this deployment, or contact whoever operates
this installation directly. Please include:

- A description of the issue and its potential impact
- Steps to reproduce it
- Any relevant logs or screenshots

We ask that you give a reasonable amount of time to address a reported
issue before any public disclosure.

## Known Limitations

In the interest of transparency:

- The CAPTCHA is a lightweight, self-hosted arithmetic challenge, not a
  commercial bot-detection service — it deters unsophisticated scripted
  attacks but not a determined, custom-built bot. Swap it for
  reCAPTCHA/hCaptcha in `captcha_render()`/`captcha_verify()`
  (`includes/functions.php`) if you need stronger bot resistance.
- The platform's Content-Security-Policy currently allows
  `'unsafe-inline'` for scripts and styles, since the application relies
  on inline `<script>`/`<style>` blocks throughout. This is a known,
  intentional trade-off — a future release may migrate to a
  nonce-based CSP for tighter script-origin control.
- Per-company encryption key derivation still traces back to one master
  key (`ENCRYPTION_KEY` in `config/config.php`). If that master key is
  compromised, all companies' secrets are ultimately at risk — the
  per-company derivation protects against key-reuse-class issues and
  provides clean separation, but is not a substitute for protecting the
  master key itself (keep `config/config.php` out of version control,
  restrict file permissions, and rotate it if you suspect compromise).