# Security Policy

## Supported branch

Security fixes target `main` until the project starts publishing release branches.

## Reporting a vulnerability

Report vulnerabilities privately through GitHub Security Advisories:

<https://github.com/gipidevdor/GPForum/security/advisories/new>

Do not open public issues for exploitable behavior, credential exposure,
authorization bypasses, session defects, data leaks, or audit integrity failures.

## Security expectations

- Authentication and session state are server-side.
- Authorization must be explicit and query-friendly.
- Audit records are append-oriented and must not be destructively modified.
- Sensitive user data belongs in dedicated tables and narrow services.
- New externally reachable behavior needs tests for failure and denial paths.

## Browser security baseline

Browser-facing responses set security headers through
`GPForum::Security::BrowserHeaders`:

- `X-Content-Type-Options: nosniff`;
- `X-Frame-Options: DENY`;
- `Referrer-Policy: strict-origin-when-cross-origin`;
- locked-down `Permissions-Policy`;
- CSP with explicit `default-src`, `script-src`, `style-src`, `img-src`,
  `font-src`, `connect-src`, `base-uri`, `form-action`, `frame-ancestors`, and
  `object-src`;
- `Strict-Transport-Security` with a one-year `includeSubDomains` max-age on
  staging and production profiles.

Sessions use SameSite Lax. Staging and production cookies are Secure.
`GPFORUM_SESSION_SECRETS` keeps previous Mojolicious secrets valid while
the current `GPFORUM_SESSION_SECRET` signs new cookies.

## SSR rendering baseline

Templates must not print untrusted raw HTML. Allowed raw HTML contexts go
through `ui_trusted_html`, backed by `GPForum::Web::RenderPolicy`.

Current allowed contexts:

- forum post bodies rendered by the server-side composer;
- search snippets generated by the PostgreSQL-native search service.