I take security seriously and want AuthPortal operators to feel confident running the latest release. This page explains which versions receive fixes and how to notify me when you spot a weakness.

Security fixes are provided for actively maintained release lines. Anything outside the windows below no longer receives updates—even for critical issues.

When a new minor series ships, the previous series remains supported for at least 90 days. I will post deprecation notices in the release notes and CHANGELOG when a branch approaches end-of-life.

I would prefer that you disclose vulnerabilities responsibly through GitHub Issues so I can track them openly while protecting sensitive details.

1. Open a new issue at https://github.com/modom-ofn/auth-portal/issues/new/choose and pick the Security report template (or the closest option available).
2. Include:
   • The exact AuthPortal version (VERSION file or Docker tag) and deployment mode.
   • Steps to reproduce or proof-of-concept payloads. Mask or redact secrets before posting.
   • Impact assessment (what could an attacker achieve, what preconditions are required).
   • Any suggested mitigations or workarounds you discovered.
3. Tag the issue with security if possible; if not, I will add it after triage.

• Acknowledgement: I review new security issues as soon as possible.
• Triage: If I need clarification, I will comment in the issue; please monitor notifications until the item is resolved.
• Resolution: Confirmed vulnerabilities are patched on the dev branch and rolled into the next tagged release. I aim to publish fixes for high-severity bugs within 14 days.
• Advisories: For issues that warrant an advisory or CVE, I will coordinate disclosure and provide upgrade guidance in the release notes and README.

If you believe the issue should remain private until a fix is available, mention that in the issue body. We can coordinate embargoed communication on a case-by-case basis.

Thank you for helping keep AuthPortal secure for everyone! Your reports make the project stronger.

AuthPortal layers AES-GCM token sealing, HTTP-only JWT sessions, RBAC authorization controls, CSP/HSTS headers, MFA gating, per-IP rate limiting, CSRF origin checks, and encrypted config/backups to protect its authentication flows, but it is still “use at your own risk,” so you should treat these controls as best-effort hardening rather than formal assurance.

Automated security checks run on this project:

• Syft SBOM + Grype: SBOM generated from the built image; Grype scans that SBOM.
• TruffleHog: secret scanning on every push/PR in CI/CD.
• git-secrets: local pre-commit and commit-message guardrail to catch credentials before they land in git history.
• GitHub CodeQL: static analysis for code-level vulnerabilities in every PR and on main.
• Trivy: container and dependency scans to catch OS and library CVEs in our images.
• Docker Scout: image-level vulnerability insights for each commit/tag, including base image and layer analysis.
• SonarQube Cloud: continuous code quality and security hotspot detection across the codebase.

If you spot an issue or have questions about these scans, please open an issue or reach out.

• Encrypted credentials: media tokens are AES-256-GCM sealed before storage, OAuth client secrets are bcrypt-hashed, and config backups reuse the same DATA_KEY, reducing impact from DB or backup leaks.
• Session hardening: signed HTTP-only JWT cookies honor SESSION_COOKIE_DOMAIN, enforce SameSite defaults, optionally force Secure, and clear pending MFA cookies whenever sessions rotate.
• Authorization hardening: admin/API access is enforced with database-backed RBAC permissions, seeded system roles (admin, viewer, user), and custom permission support for downstream-app entitlements.
• Rate limits plus MFA: shared per-IP limiters guard login/start-forward flows, separate limiters protect Plex polling/MFA endpoints, and enforced MFA can hold users at a pending cookie until codes succeed.
• CSRF-lite controls: every state-changing route (start-web, forward, MFA APIs, logout) passes through an Origin/Referer validator that builds an allowlist from APP_BASE_URL and proxy headers.
• Security headers: all responses carry X-Frame-Options, X-Content-Type-Options, Referrer-Policy, a restrictive CSP, and conditional Strict-Transport-Security (or forceable via FORCE_HSTS).
• Config governance: provider/security/MFA/App Settings/LDAP Sync config lives in Postgres with optimistic versioning, in-browser history, scheduled backups, and download/restore flows for recovery.
• Admin audit visibility: the Logs tab aggregates persisted admin audit history across supported modules and exposes a buffered live log stream only to authenticated admins.
• LDAP sync safety rails: built-in LDAP Sync supports connection testing before save/run, optional LDAP group-to-role mapping, logs per-user failures, tracks scheduled/manual runs, and only deletes stale entries that were previously marked as AuthPortal-managed under the configured Base DN.
• Token privacy for OIDC: access/refresh tokens are stored as deterministic SHA-256 digests, limiting exposure if databases or logs leak.
• OAuth governance: OAuth client changes now produce persistent server-side audit history with operator-supplied change reasons, and custom OAuth scopes are validated against the RBAC permission catalog before they can be assigned or granted.
• Operational logging caution: because the admin Logs tab can surface recent application log lines in-browser, operators should avoid writing secrets to logs and should keep admin.access assignments tightly scoped.
• Runtime hygiene: containers are built with Docker Hardened Images for both build and runtime (dhi.io/golang:1.26.5-alpine3.23-dev -> dhi.io/alpine-base:3.23-alpine3.23), keep only CA certs/tzdata in the final layer, and run as non-root UID 65532 to shrink the attack surface.