Merge pull request #913 from Wikid82/bot/update-geolite2-checksum

chore(docker): update GeoLite2-Country.mmdb checksum

.docker/compose/docker-compose.playwright-local.yml

@@ -48,7 +48,8 @@ services:
     tmpfs:
       # True tmpfs for E2E test data - fresh on every run, in-memory only
       # mode=1777 allows any user to write (container runs as non-root)
-      - /app/data:size=100M,mode=1777
+      # 256M gives headroom for the backup service's 100MB disk-space check
+      - /app/data:size=256M,mode=1777
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock:ro # For container discovery in tests
     healthcheck:

.github/renovate.json

@@ -130,6 +130,32 @@
       "datasourceTemplate": "go",
       "versioningTemplate": "semver"
     },
+    {
+      "customType": "regex",
+      "description": "Track gotestsum version in codecov workflow",
+      "managerFilePatterns": [
+        "/^\\.github/workflows/codecov-upload\\.yml$/"
+      ],
+      "matchStrings": [
+        "gotestsum@v(?<currentValue>[^\\s]+)"
+      ],
+      "depNameTemplate": "gotest.tools/gotestsum",
+      "datasourceTemplate": "go",
+      "versioningTemplate": "semver"
+    },
+    {
+      "customType": "regex",
+      "description": "Track gotestsum version in quality checks workflow",
+      "managerFilePatterns": [
+        "/^\\.github/workflows/quality-checks\\.yml$/"
+      ],
+      "matchStrings": [
+        "gotestsum@v(?<currentValue>[^\\s]+)"
+      ],
+      "depNameTemplate": "gotest.tools/gotestsum",
+      "datasourceTemplate": "go",
+      "versioningTemplate": "semver"
+    },
     {
       "customType": "regex",
       "description": "Track govulncheck version in scripts",
@@ -255,6 +281,12 @@
       "matchUpdateTypes": ["major"],
       "automerge": false,
       "labels": ["manual-review"]
+    },
+    {
+      "description": "Fix Renovate lookup for geoip2-golang v2 module path",
+      "matchDatasources": ["go"],
+      "matchPackageNames": ["github.com/oschwald/geoip2-golang/v2"],
+      "sourceUrl": "https://github.com/oschwald/geoip2-golang"
     }
   ]
 }

.github/workflows/codecov-upload.yml

@@ -126,6 +126,9 @@ jobs:
             echo "__CHARON_EOF__"
           } >> "$GITHUB_ENV"
 
+      - name: Install gotestsum
+        run: go install gotest.tools/gotestsum@v1.13.0
+
       - name: Run Go tests with coverage
         working-directory: ${{ github.workspace }}
         env:
@@ -134,6 +137,14 @@ jobs:
           bash scripts/go-test-coverage.sh 2>&1 | tee backend/test-output.txt
           exit "${PIPESTATUS[0]}"
 
+      - name: Upload test output artifact
+        if: always()
+        uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
+        with:
+          name: backend-test-output
+          path: backend/test-output.txt
+          retention-days: 7
+
       - name: Upload backend coverage to Codecov
         uses: codecov/codecov-action@1af58845a975a7985b0beb0cbe6fbbb71a41dbad # v5
         with:

.github/workflows/docker-build.yml

@@ -23,7 +23,7 @@ name: Docker Build, Publish & Test
 on:
   pull_request:
   push:
-    branches: [main]
+    branches: [main, development]
   workflow_dispatch:
   workflow_run:
     workflows: ["Docker Lint"]
@@ -42,7 +42,7 @@ env:
   TRIGGER_HEAD_SHA: ${{ github.event_name == 'workflow_run' && github.event.workflow_run.head_sha || github.sha }}
   TRIGGER_REF: ${{ github.event_name == 'workflow_run' && format('refs/heads/{0}', github.event.workflow_run.head_branch) || github.ref }}
   TRIGGER_HEAD_REF: ${{ github.event_name == 'workflow_run' && github.event.workflow_run.head_branch || github.head_ref }}
-  TRIGGER_PR_NUMBER: ${{ github.event_name == 'workflow_run' && join(github.event.workflow_run.pull_requests.*.number, '') || github.event.pull_request.number }}
+  TRIGGER_PR_NUMBER: ${{ github.event_name == 'workflow_run' && join(github.event.workflow_run.pull_requests.*.number, '') || format('{0}', github.event.pull_request.number) }}
   TRIGGER_ACTOR: ${{ github.event_name == 'workflow_run' && github.event.workflow_run.actor.login || github.actor }}
 
 jobs:

.github/workflows/quality-checks.yml

@@ -148,6 +148,9 @@ jobs:
         run: |
           bash "scripts/repo_health_check.sh"
 
+      - name: Install gotestsum
+        run: go install gotest.tools/gotestsum@v1.13.0
+
       - name: Run Go tests
         id: go-tests
         working-directory: ${{ github.workspace }}
@@ -156,6 +159,14 @@ jobs:
         run: |
           bash "scripts/go-test-coverage.sh" 2>&1 | tee backend/test-output.txt; exit "${PIPESTATUS[0]}"
 
+      - name: Upload test output artifact
+        if: always()
+        uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
+        with:
+          name: backend-test-output
+          path: backend/test-output.txt
+          retention-days: 7
+
       - name: Go Test Summary
         if: always()
         working-directory: backend

.github/workflows/renovate.yml

@@ -25,7 +25,7 @@ jobs:
           fetch-depth: 1
 
       - name: Run Renovate
-        uses: renovatebot/github-action@abd08c7549b2a864af5df4a2e369c43f035a6a9d # v46.1.5
+        uses: renovatebot/github-action@68a3ea99af6ad249940b5a9fdf44fc6d7f14378b # v46.1.6
         with:
           configurationFile: .github/renovate.json
           token: ${{ secrets.RENOVATE_TOKEN || secrets.GITHUB_TOKEN }}

.github/workflows/security-pr.yml

@@ -385,7 +385,7 @@ jobs:
       - name: Upload Trivy SARIF to GitHub Security
         if: always() && steps.trivy-sarif-check.outputs.exists == 'true'
         # github/codeql-action v4
-        uses: github/codeql-action/upload-sarif@05b1a5d28f8763fd11e77388fe57846f1ba8e766
+        uses: github/codeql-action/upload-sarif@eedab83377f873ae39009d167a89b7a5aab4638b
         with:
           sarif_file: 'trivy-binary-results.sarif'
           category: ${{ steps.pr-info.outputs.is_push == 'true' && format('security-scan-{0}', github.event_name == 'workflow_run' && github.event.workflow_run.head_branch || github.ref_name) || format('security-scan-pr-{0}', steps.pr-info.outputs.pr_number) }}

.grype.yaml

@@ -4,83 +4,6 @@
 # Documentation: https://github.com/anchore/grype#specifying-matches-to-ignore
 
 ignore:
-  # GHSA-69x3-g4r3-p962 / CVE-2026-25793: Nebula ECDSA Signature Malleability
-  # Severity: HIGH (CVSS 8.1)
-  # Package: github.com/slackhq/nebula v1.9.7 (embedded in /usr/bin/caddy)
-  # Status: Cannot upgrade — smallstep/certificates v0.30.0-rc2 still pins nebula v1.9.x
-  #
-  # Vulnerability Details:
-  # - ECDSA signature malleability allows bypassing certificate blocklists
-  # - Attacker can forge alternate valid P256 ECDSA signatures for revoked
-  #   certificates (CVSSv3: AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N)
-  # - Only affects configurations using Nebula-based certificate authorities
-  #   (non-default and uncommon in Charon deployments)
-  #
-  # Root Cause (Compile-Time Dependency Lock):
-  # - Caddy is built with caddy-security plugin, which transitively requires
-  #   github.com/smallstep/certificates. That package pins nebula v1.9.x.
-  # - Checked: smallstep/certificates v0.27.5 → v0.30.0-rc2 all require nebula v1.9.4–v1.9.7.
-  #   The nebula v1.10 API removal breaks compilation in the
-  #   authority/provisioner package; xcaddy build fails with upgrade attempted.
-  # - Dockerfile caddy-builder stage pins nebula@v1.9.7 (Renovate tracked) with
-  #   an inline comment explaining the constraint (Dockerfile line 247).
-  # - Fix path: once smallstep/certificates releases a version requiring
-  #   nebula v1.10+, remove the pin and this suppression simultaneously.
-  #
-  # Risk Assessment: ACCEPTED (Low exploitability in Charon context)
-  # - Charon uses standard ACME/Let's Encrypt TLS; Nebula VPN PKI is not
-  #   enabled by default and rarely configured in Charon deployments.
-  # - Exploiting this requires a valid certificate sharing the same issuer as
-  #   a revoked one — an uncommon and targeted attack scenario.
-  # - Container-level isolation reduces the attack surface further.
-  #
-  # Mitigation (active while suppression is in effect):
-  # - Monitor smallstep/certificates releases at https://github.com/smallstep/certificates/releases
-  # - Weekly CI security rebuild flags any new CVEs in the full image.
-  # - Renovate annotation in Dockerfile (datasource=go depName=github.com/slackhq/nebula)
-  #   will surface the pin for review when xcaddy build becomes compatible.
-  #
-  # Review:
-  # - Reviewed 2026-02-19: smallstep/certificates latest stable remains v0.27.5;
-  #   no release requiring nebula v1.10+ has shipped. Suppression extended 14 days.
-  # - Reviewed 2026-03-13: smallstep/certificates stable still v0.27.5, extended 30 days.
-  # - Next review: 2026-04-12. Remove suppression immediately once upstream fixes.
-  #
-  # Removal Criteria:
-  # - smallstep/certificates releases a stable version requiring nebula v1.10+
-  # - Update Dockerfile caddy-builder patch to use the new versions
-  # - Rebuild image, run security scan, confirm suppression no longer needed
-  # - Remove both this entry and the corresponding .trivyignore entry
-  #
-  # References:
-  # - GHSA: https://github.com/advisories/GHSA-69x3-g4r3-p962
-  # - CVE-2026-25793: https://nvd.nist.gov/vuln/detail/CVE-2026-25793
-  # - smallstep/certificates: https://github.com/smallstep/certificates/releases
-  # - Dockerfile pin: caddy-builder stage, line ~247 (go get nebula@v1.9.7)
-  - vulnerability: GHSA-69x3-g4r3-p962
-    package:
-      name: github.com/slackhq/nebula
-      version: "v1.9.7"
-      type: go-module
-    reason: |
-      HIGH — ECDSA signature malleability in nebula v1.9.7 embedded in /usr/bin/caddy.
-      Cannot upgrade: smallstep/certificates v0.27.5 (latest stable as of 2026-03-13)
-      still requires nebula v1.9.x (verified across v0.27.5–v0.30.0-rc2). Charon does
-      not use Nebula VPN PKI by default. Risk accepted pending upstream smallstep fix.
-      Reviewed 2026-03-13: smallstep/certificates stable still v0.27.5, extended 30 days.
-    expiry: "2026-04-12"  # Re-evaluated 2026-03-13: smallstep/certificates stable still v0.27.5, extended 30 days.
-
-    # Action items when this suppression expires:
-    # 1. Check smallstep/certificates releases: https://github.com/smallstep/certificates/releases
-    # 2. If a stable version requires nebula v1.10+:
-    #    a. Update Dockerfile caddy-builder: remove the `go get nebula@v1.9.7` pin
-    #    b. Optionally bump smallstep/certificates to the new version
-    #    c. Rebuild Docker image and verify no compile failures
-    #    d. Re-run local security-scan-docker-image and confirm clean result
-    #    e. Remove this suppression entry
-    # 3. If no fix yet: Extend expiry by 14 days and document justification
-    # 4. If extended 3+ times: Open upstream issue on smallstep/certificates
-
   # CVE-2026-2673: OpenSSL TLS 1.3 server key exchange group downgrade
   # Severity: HIGH (CVSS 7.5)
   # Packages: libcrypto3 3.5.5-r0 and libssl3 3.5.5-r0 (Alpine apk)
@@ -153,161 +76,6 @@ ignore:
       Risk accepted pending Alpine upstream patch.
     expiry: "2026-04-18"  # Initial 30-day review period. See libcrypto3 entry above for action items.
 
-  # CVE-2026-33186 / GHSA-p77j-4mvh-x3m3: gRPC-Go authorization bypass via missing leading slash
-  # Severity: CRITICAL (CVSS 9.1)
-  # Package: google.golang.org/grpc v1.74.2 (embedded in /usr/local/bin/crowdsec and /usr/local/bin/cscli)
-  # Status: Fix available at v1.79.3 — waiting on CrowdSec upstream to release with patched grpc
-  #
-  # Vulnerability Details:
-  # - gRPC-Go server path-based authorization (grpc/authz) fails to match deny rules when
-  #   the HTTP/2 :path pseudo-header is missing its leading slash (e.g., "Service/Method"
-  #   instead of "/Service/Method"), allowing a fallback allow-rule to grant access instead.
-  # - CVSSv3: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
-  #
-  # Root Cause (Third-Party Binary):
-  # - Charon's own grpc dependency is patched to v1.79.3 (updated 2026-03-19).
-  # - CrowdSec ships grpc v1.74.2 compiled into its binary; Charon has no control over this.
-  # - This is a server-side vulnerability. CrowdSec uses grpc as a server; Charon uses it
-  #   only as a client (via the Docker SDK). CrowdSec's internal grpc server is not exposed
-  #   to external traffic in a standard Charon deployment.
-  # - Fix path: once CrowdSec releases a version built with grpc >= v1.79.3, rebuild the
-  #   Docker image (Renovate tracks the CrowdSec version) and remove this suppression.
-  #
-  # Risk Assessment: ACCEPTED (Constrained exploitability in Charon context)
-  # - The vulnerable code path requires an attacker to reach CrowdSec's internal grpc server,
-  #   which is bound to localhost/internal interfaces in the Charon container network.
-  # - Container-level isolation (no exposed grpc port) significantly limits exposure.
-  # - Charon does not configure grpc/authz deny rules on CrowdSec's server.
-  #
-  # Mitigation (active while suppression is in effect):
-  # - Monitor CrowdSec releases: https://github.com/crowdsecurity/crowdsec/releases
-  # - Weekly CI security rebuild flags the moment a fixed CrowdSec image ships.
-  #
-  # Review:
-  # - Reviewed 2026-03-19 (initial suppression): grpc v1.79.3 fix exists; CrowdSec has not
-  #   yet shipped an updated release. Suppression set for 14-day review given fix availability.
-  # - Next review: 2026-04-02. Remove suppression once CrowdSec ships with grpc >= v1.79.3.
-  #
-  # Removal Criteria:
-  # - CrowdSec releases a version built with google.golang.org/grpc >= v1.79.3
-  # - Rebuild Docker image, run security-scan-docker-image, confirm finding is resolved
-  # - Remove this entry and the corresponding .trivyignore entry simultaneously
-  #
-  # References:
-  # - GHSA-p77j-4mvh-x3m3: https://github.com/advisories/GHSA-p77j-4mvh-x3m3
-  # - CVE-2026-33186: https://nvd.nist.gov/vuln/detail/CVE-2026-33186
-  # - grpc fix (v1.79.3): https://github.com/grpc/grpc-go/releases/tag/v1.79.3
-  # - CrowdSec releases: https://github.com/crowdsecurity/crowdsec/releases
-  - vulnerability: CVE-2026-33186
-    package:
-      name: google.golang.org/grpc
-      version: "v1.74.2"
-      type: go-module
-    reason: |
-      CRITICAL — gRPC-Go authorization bypass in grpc v1.74.2 embedded in /usr/local/bin/crowdsec
-      and /usr/local/bin/cscli. Fix available at v1.79.3 (Charon's own dep is patched); waiting
-      on CrowdSec upstream to release with patched grpc. CrowdSec's grpc server is not exposed
-      externally in a standard Charon deployment. Risk accepted pending CrowdSec upstream fix.
-      Reviewed 2026-03-19: CrowdSec has not yet released with grpc >= v1.79.3.
-    expiry: "2026-04-02"  # 14-day review: fix exists at v1.79.3; check CrowdSec releases.
-
-    # Action items when this suppression expires:
-    # 1. Check CrowdSec releases: https://github.com/crowdsecurity/crowdsec/releases
-    # 2. If CrowdSec ships with grpc >= v1.79.3:
-    #    a. Renovate should auto-PR the new CrowdSec version in the Dockerfile
-    #    b. Merge the Renovate PR, rebuild Docker image
-    #    c. Run local security-scan-docker-image and confirm grpc v1.74.2 is gone
-    #    d. Remove this suppression entry and the corresponding .trivyignore entry
-    # 3. If no fix yet: Extend expiry by 14 days and document justification
-    # 4. If extended 3+ times: Open an upstream issue on crowdsecurity/crowdsec
-
-  # CVE-2026-33186 (Caddy) — see full justification in the CrowdSec entry above
-  # Package: google.golang.org/grpc v1.79.1 (embedded in /usr/bin/caddy)
-  # Status: Fix available at v1.79.3 — waiting on a new Caddy release built with patched grpc
-  - vulnerability: CVE-2026-33186
-    package:
-      name: google.golang.org/grpc
-      version: "v1.79.1"
-      type: go-module
-    reason: |
-      CRITICAL — gRPC-Go authorization bypass in grpc v1.79.1 embedded in /usr/bin/caddy.
-      Fix available at v1.79.3; waiting on Caddy upstream to release a build with patched grpc.
-      Caddy's grpc server is not exposed externally in a standard Charon deployment.
-      Risk accepted pending Caddy upstream fix. Reviewed 2026-03-19: no Caddy release with grpc >= v1.79.3 yet.
-    expiry: "2026-04-02"  # 14-day review: fix exists at v1.79.3; check Caddy releases.
-
-    # Action items when this suppression expires:
-    # 1. Check Caddy releases: https://github.com/caddyserver/caddy/releases
-    #    (or the custom caddy-builder in the Dockerfile for caddy-security plugin)
-    # 2. If a new Caddy build ships with grpc >= v1.79.3:
-    #    a. Update the Caddy version pin in the Dockerfile caddy-builder stage
-    #    b. Rebuild Docker image and run local security-scan-docker-image
-    #    c. Remove this suppression entry and the corresponding .trivyignore entry
-    # 3. If no fix yet: Extend expiry by 14 days and document justification
-    # 4. If extended 3+ times: Open an issue on caddyserver/caddy
-
-  # GHSA-479m-364c-43vc: goxmldsig XML signature validation bypass (loop variable capture)
-  # Severity: HIGH (CVSS 7.5)
-  # Package: github.com/russellhaering/goxmldsig v1.5.0 (embedded in /usr/bin/caddy)
-  # Status: Fix available at v1.6.0 — waiting on a new Caddy release built with patched goxmldsig
-  #
-  # Vulnerability Details:
-  # - Loop variable capture in validateSignature causes the signature reference to always
-  #   point to the last element in SignedInfo.References; an attacker can substitute signed
-  #   element content and bypass XML signature integrity validation (CWE-347, CWE-682).
-  # - CVSSv3: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
-  #
-  # Root Cause (Third-Party Binary):
-  # - Charon does not use goxmldsig directly. The package is compiled into /usr/bin/caddy
-  #   via the caddy-security plugin's SAML/SSO support.
-  # - Fix path: once Caddy (or the caddy-security plugin) releases a build with
-  #   goxmldsig >= v1.6.0, rebuild the Docker image and remove this suppression.
-  #
-  # Risk Assessment: ACCEPTED (Low exploitability in default Charon context)
-  # - The vulnerability only affects SAML/XML signature validation workflows.
-  # - Charon does not enable or configure SAML-based SSO in its default setup.
-  # - Exploiting this requires an active SAML integration, which is non-default.
-  #
-  # Mitigation (active while suppression is in effect):
-  # - Monitor caddy-security plugin releases: https://github.com/greenpau/caddy-security/releases
-  # - Monitor Caddy releases: https://github.com/caddyserver/caddy/releases
-  # - Weekly CI security rebuild flags the moment a fixed image ships.
-  #
-  # Review:
-  # - Reviewed 2026-03-19 (initial suppression): goxmldsig v1.6.0 fix exists; Caddy has not
-  #   yet shipped with the updated dep. Set 14-day review given fix availability.
-  # - Next review: 2026-04-02. Remove suppression once Caddy ships with goxmldsig >= v1.6.0.
-  #
-  # Removal Criteria:
-  # - Caddy (or caddy-security plugin) releases a build with goxmldsig >= v1.6.0
-  # - Rebuild Docker image, run security-scan-docker-image, confirm finding is resolved
-  # - Remove this entry and the corresponding .trivyignore entry simultaneously
-  #
-  # References:
-  # - GHSA-479m-364c-43vc: https://github.com/advisories/GHSA-479m-364c-43vc
-  # - goxmldsig v1.6.0 fix: https://github.com/russellhaering/goxmldsig/releases/tag/v1.6.0
-  # - caddy-security plugin: https://github.com/greenpau/caddy-security/releases
-  - vulnerability: GHSA-479m-364c-43vc
-    package:
-      name: github.com/russellhaering/goxmldsig
-      version: "v1.5.0"
-      type: go-module
-    reason: |
-      HIGH — XML signature validation bypass in goxmldsig v1.5.0 embedded in /usr/bin/caddy.
-      Fix available at v1.6.0; waiting on Caddy upstream to release a build with patched goxmldsig.
-      Charon does not configure SAML-based SSO by default; the vulnerable XML signature path
-      is not reachable in a standard deployment. Risk accepted pending Caddy upstream fix.
-      Reviewed 2026-03-19: no Caddy release with goxmldsig >= v1.6.0 yet.
-    expiry: "2026-04-02"  # 14-day review: fix exists at v1.6.0; check Caddy/caddy-security releases.
-
-    # Action items when this suppression expires:
-    # 1. Check caddy-security releases: https://github.com/greenpau/caddy-security/releases
-    # 2. If a new build ships with goxmldsig >= v1.6.0:
-    #    a. Update the Caddy version pin in the Dockerfile caddy-builder stage if needed
-    #    b. Rebuild Docker image and run local security-scan-docker-image
-    #    c. Remove this suppression entry and the corresponding .trivyignore entry
-    # 3. If no fix yet: Extend expiry by 14 days and document justification
-
   # GHSA-6g7g-w4f8-9c9x: buger/jsonparser Delete panic on malformed JSON (DoS)
   # Severity: HIGH (CVSS 7.5)
   # Package: github.com/buger/jsonparser v1.1.1 (embedded in /usr/local/bin/crowdsec and /usr/local/bin/cscli)

ARCHITECTURE.md

@@ -306,11 +306,13 @@ graph TB
 **Key Modules:**
 
 #### API Layer (`internal/api/`)
+
 - **Handlers:** Process HTTP requests, validate input, return responses
 - **Middleware:** CORS, GZIP, authentication, logging, metrics, panic recovery
 - **Routes:** Route registration and grouping (public vs authenticated)
 
 **Example Endpoints:**
+
 - `GET /api/v1/proxy-hosts` - List all proxy hosts
 - `POST /api/v1/proxy-hosts` - Create new proxy host
 - `PUT /api/v1/proxy-hosts/:id` - Update proxy host
@@ -318,6 +320,7 @@ graph TB
 - `WS /api/v1/logs` - WebSocket for real-time logs
 
 #### Service Layer (`internal/services/`)
+
 - **ProxyService:** CRUD operations for proxy hosts, validation logic
 - **CertificateService:** ACME certificate provisioning and renewal
 - **DockerService:** Container discovery and monitoring
@@ -327,12 +330,14 @@ graph TB
 **Design Pattern:** Services contain business logic and call multiple repositories/managers
 
 #### Caddy Manager (`internal/caddy/`)
+
 - **Manager:** Orchestrates Caddy configuration updates
 - **Config Builder:** Generates Caddy JSON from database models
 - **Reload Logic:** Atomic config application with rollback on failure
 - **Security Integration:** Injects Cerberus middleware into Caddy pipelines
 
 **Responsibilities:**
+
 1. Generate Caddy JSON configuration from database state
 2. Validate configuration before applying
 3. Trigger Caddy reload via JSON API
@@ -340,22 +345,26 @@ graph TB
 5. Integrate security layers (WAF, ACL, Rate Limiting)
 
 #### Security Suite (`internal/cerberus/`)
+
 - **ACL (Access Control Lists):** IP-based allow/deny rules, GeoIP blocking
 - **WAF (Web Application Firewall):** Coraza engine with OWASP CRS
 - **CrowdSec:** Behavior-based threat detection with global intelligence
 - **Rate Limiter:** Per-IP request throttling
 
 **Integration Points:**
+
 - Middleware injection into Caddy request pipeline
 - Database-driven rule configuration
 - Metrics collection for security events
 
 #### Database Layer (`internal/database/`)
+
 - **Migrations:** Automatic schema versioning with GORM AutoMigrate
 - **Seeding:** Default settings and admin user creation
 - **Connection Management:** SQLite with WAL mode and connection pooling
 
 **Schema Overview:**
+
 - **ProxyHost:** Domain, upstream target, SSL config
 - **RemoteServer:** Upstream server definitions
 - **CaddyConfig:** Generated Caddy configuration (audit trail)
@@ -372,6 +381,7 @@ graph TB
 **Component Architecture:**
 
 #### Pages (`src/pages/`)
+
 - **Dashboard:** System overview, recent activity, quick actions
 - **ProxyHosts:** List, create, edit, delete proxy configurations
 - **Certificates:** Manage SSL/TLS certificates, view expiry
@@ -380,17 +390,20 @@ graph TB
 - **Users:** User management (admin only)
 
 #### Components (`src/components/`)
+
 - **Forms:** Reusable form inputs with validation
 - **Modals:** Dialog components for CRUD operations
 - **Tables:** Data tables with sorting, filtering, pagination
 - **Layout:** Header, sidebar, navigation
 
 #### API Client (`src/api/`)
+
 - Centralized API calls with error handling
 - Request/response type definitions
 - Authentication token management
 
 **Example:**
+
 ```typescript
 export const getProxyHosts = async (): Promise<ProxyHost[]> => {
   const response = await fetch('/api/v1/proxy-hosts', {
@@ -402,11 +415,13 @@ export const getProxyHosts = async (): Promise<ProxyHost[]> => {
 ```
 
 #### State Management
+
 - **React Context:** Global state for auth, theme, language
 - **Local State:** Component-specific state with `useState`
 - **Custom Hooks:** Encapsulate API calls and side effects
 
 **Example Hook:**
+
 ```typescript
 export const useProxyHosts = () => {
   const [hosts, setHosts] = useState<ProxyHost[]>([]);
@@ -425,11 +440,13 @@ export const useProxyHosts = () => {
 **Purpose:** High-performance reverse proxy with automatic HTTPS
 
 **Integration:**
+
 - Embedded as a library in the Go backend
 - Configured via JSON API (not Caddyfile)
 - Listens on ports 80 (HTTP) and 443 (HTTPS)
 
 **Features Used:**
+
 - Dynamic configuration updates without restarts
 - Automatic HTTPS with Let's Encrypt and ZeroSSL
 - DNS challenge support for wildcard certificates
@@ -437,6 +454,7 @@ export const useProxyHosts = () => {
 - Request logging and metrics
 
 **Configuration Flow:**
+
 1. User creates proxy host via frontend
 2. Backend validates and saves to database
 3. Caddy Manager generates JSON configuration
@@ -461,12 +479,14 @@ For each proxy host, Charon generates **two routes** with the same domain:
    - Handlers: Full Cerberus security suite
 
 This pattern is **intentional and valid**:
+
 - Emergency route provides break-glass access to security controls
 - Main route protects application with enterprise security features
 - Caddy processes routes in order (emergency matches first)
 - Validator allows duplicate hosts when one has paths and one doesn't
 
 **Example:**
+
 ```json
 // Emergency Route (evaluated first)
 {
@@ -488,6 +508,7 @@ This pattern is **intentional and valid**:
 **Purpose:** Persistent data storage
 
 **Why SQLite:**
+
 - Embedded (no external database server)
 - Serverless (perfect for single-user/small team)
 - ACID compliant with WAL mode
@@ -495,16 +516,19 @@ This pattern is **intentional and valid**:
 - Backup-friendly (single file)
 
 **Configuration:**
+
 - **WAL Mode:** Allows concurrent reads during writes
 - **Foreign Keys:** Enforced referential integrity
 - **Pragma Settings:** Performance optimizations
 
 **Backup Strategy:**
+
 - Automated daily backups to `data/backups/`
 - Retention: 7 daily, 4 weekly, 12 monthly backups
 - Backup during low-traffic periods
 
 **Migrations:**
+
 - GORM AutoMigrate for schema changes
 - Manual migrations for complex data transformations
 - Rollback support via backup restoration
@@ -537,6 +561,7 @@ graph LR
 **Purpose:** Prevent brute-force attacks and API abuse
 
 **Implementation:**
+
 - Per-IP request counters with sliding window
 - Configurable thresholds (e.g., 100 req/min, 1000 req/hour)
 - HTTP 429 response when limit exceeded
@@ -547,12 +572,14 @@ graph LR
 **Purpose:** Behavior-based threat detection
 
 **Features:**
+
 - Local log analysis (brute-force, port scans, exploits)
 - Global threat intelligence (crowd-sourced IP reputation)
 - Automatic IP banning with configurable duration
 - Decision management API (view, create, delete bans)
 
 **Modes:**
+
 - **Local Only:** No external API calls
 - **API Mode:** Sync with CrowdSec cloud for global intelligence
 
@@ -561,12 +588,14 @@ graph LR
 **Purpose:** IP-based access control
 
 **Features:**
+
 - Per-proxy-host allow/deny rules
 - CIDR range support (e.g., `192.168.1.0/24`)
 - Geographic blocking via GeoIP2 (MaxMind)
 - Admin whitelist (emergency access)
 
 **Evaluation Order:**
+
 1. Check admin whitelist (always allow)
 2. Check deny list (explicit block)
 3. Check allow list (explicit allow)
@@ -579,6 +608,7 @@ graph LR
 **Engine:** Coraza with OWASP Core Rule Set (CRS)
 
 **Detection Categories:**
+
 - SQL Injection (SQLi)
 - Cross-Site Scripting (XSS)
 - Remote Code Execution (RCE)
@@ -587,12 +617,14 @@ graph LR
 - Command Injection
 
 **Modes:**
+
 - **Monitor:** Log but don't block (testing)
 - **Block:** Return HTTP 403 for violations
 
 ### Layer 5: Application Security
 
 **Additional Protections:**
+
 - **SSRF Prevention:** Block requests to private IP ranges in webhooks/URL validation
 - **HTTP Security Headers:** CSP, HSTS, X-Frame-Options, X-Content-Type-Options
 - **Input Validation:** Server-side validation for all user inputs
@@ -610,6 +642,7 @@ graph LR
 3. **Direct Database Access:** Manual SQLite update as last resort
 
 **Emergency Token:**
+
 - 64-character hex token set via `CHARON_EMERGENCY_TOKEN`
 - Grants temporary admin access
 - Rotated after each use
@@ -635,6 +668,7 @@ Charon operates with **two distinct traffic flows** on separate ports, each with
 - **Testing:** Playwright E2E tests verify UI/UX functionality on this port
 
 **Why No Middleware?**
+
 - Management interface must remain accessible even when security modules are misconfigured
 - Emergency endpoints (`/api/v1/emergency/*`) require unrestricted access for system recovery
 - Separation of concerns: admin access control is handled by JWT, not proxy-level security
@@ -797,6 +831,7 @@ sequenceDiagram
 **Rationale:** Simplicity over scalability - target audience is home users and small teams
 
 **Container Contents:**
+
 - Frontend static files (Vite build output)
 - Go backend binary
 - Embedded Caddy server
@@ -911,11 +946,13 @@ services:
 ### High Availability Considerations
 
 **Current Limitations:**
+
 - SQLite does not support clustering
 - Single point of failure (one container)
 - Not designed for horizontal scaling
 
 **Future Options:**
+
 - PostgreSQL backend for HA deployments
 - Read replicas for load balancing
 - Container orchestration (Kubernetes, Docker Swarm)
@@ -927,6 +964,7 @@ services:
 ### Local Development Setup
 
 1. **Prerequisites:**
+
    ```bash
    - Go 1.26+ (backend development)
    - Node.js 23+ and npm (frontend development)
@@ -935,12 +973,14 @@ services:
    ```
 
 2. **Clone Repository:**
+
    ```bash
    git clone https://github.com/Wikid82/Charon.git
    cd Charon
    ```
 
 3. **Backend Development:**
+
    ```bash
    cd backend
    go mod download
@@ -949,6 +989,7 @@ services:
    ```
 
 4. **Frontend Development:**
+
    ```bash
    cd frontend
    npm install
@@ -957,6 +998,7 @@ services:
    ```
 
 5. **Full-Stack Development (Docker):**
+
    ```bash
    docker-compose -f .docker/compose/docker-compose.dev.yml up
    # Frontend + Backend + Caddy in one container
@@ -965,12 +1007,14 @@ services:
 ### Git Workflow
 
 **Branch Strategy:**
+
 - `main`: Stable production branch
 - `feature/*`: New feature development
 - `fix/*`: Bug fixes
 - `chore/*`: Maintenance tasks
 
 **Commit Convention:**
+
 - `feat:` New user-facing feature
 - `fix:` Bug fix in application code
 - `chore:` Infrastructure, CI/CD, dependencies
@@ -979,6 +1023,7 @@ services:
 - `test:` Adding or updating tests
 
 **Example:**
+
 ```
 feat: add DNS-01 challenge support for Cloudflare
 
@@ -1031,6 +1076,7 @@ Closes #123
 **Purpose:** Validate critical user flows in a real browser
 
 **Scope:**
+
 - User authentication
 - Proxy host CRUD operations
 - Certificate provisioning
@@ -1038,6 +1084,7 @@ Closes #123
 - Real-time log streaming
 
 **Execution:**
+
 ```bash
 # Run against Docker container
 npx playwright test --project=chromium
@@ -1050,10 +1097,12 @@ npx playwright test --debug
 ```
 
 **Coverage Modes:**
+
 - **Docker Mode:** Integration testing, no coverage (0% reported)
 - **Vite Dev Mode:** Coverage collection with V8 inspector
 
 **Why Two Modes?**
+
 - Playwright coverage requires source maps and raw source files
 - Docker serves pre-built production files (no source maps)
 - Vite dev server exposes source files for coverage instrumentation
@@ -1067,6 +1116,7 @@ npx playwright test --debug
 **Coverage Target:** 85% minimum
 
 **Execution:**
+
 ```bash
 # Run all tests
 go test ./...
@@ -1079,11 +1129,13 @@ go test -cover ./...
 ```
 
 **Test Organization:**
+
 - `*_test.go` files alongside source code
 - Table-driven tests for comprehensive coverage
 - Mocks for external dependencies (database, HTTP clients)
 
 **Example:**
+
 ```go
 func TestCreateProxyHost(t *testing.T) {
     tests := []struct {
@@ -1123,6 +1175,7 @@ func TestCreateProxyHost(t *testing.T) {
 **Coverage Target:** 85% minimum
 
 **Execution:**
+
 ```bash
 # Run all tests
 npm test
@@ -1135,6 +1188,7 @@ npm run test:coverage
 ```
 
 **Test Organization:**
+
 - `*.test.tsx` files alongside components
 - Mock API calls with MSW (Mock Service Worker)
 - Snapshot tests for UI consistency
@@ -1146,12 +1200,14 @@ npm run test:coverage
 **Location:** `backend/integration/`
 
 **Scope:**
+
 - API endpoint end-to-end flows
 - Database migrations
 - Caddy manager integration
 - CrowdSec API calls
 
 **Execution:**
+
 ```bash
 go test ./integration/...
 ```
@@ -1161,6 +1217,7 @@ go test ./integration/...
 **Automated Hooks (via `.pre-commit-config.yaml`):**
 
 **Fast Stage (< 5 seconds):**
+
 - Trailing whitespace removal
 - EOF fixer
 - YAML syntax check
@@ -1168,11 +1225,13 @@ go test ./integration/...
 - Markdown link validation
 
 **Manual Stage (run explicitly):**
+
 - Backend coverage tests (60-90s)
 - Frontend coverage tests (30-60s)
 - TypeScript type checking (10-20s)
 
 **Why Manual?**
+
 - Coverage tests are slow and would block commits
 - Developers run them on-demand before pushing
 - CI enforces coverage on pull requests
@@ -1180,10 +1239,12 @@ go test ./integration/...
 ### Continuous Integration (GitHub Actions)
 
 **Workflow Triggers:**
+
 - `push` to `main`, `feature/*`, `fix/*`
 - `pull_request` to `main`
 
 **CI Jobs:**
+
 1. **Lint:** golangci-lint, ESLint, markdownlint, hadolint
 2. **Test:** Go tests, Vitest, Playwright
 3. **Security:** Trivy, CodeQL, Grype, Govulncheck
@@ -1205,6 +1266,7 @@ go test ./integration/...
 - **PRERELEASE:** `-beta.1`, `-rc.1`, etc.
 
 **Examples:**
+
 - `1.0.0` - Stable release
 - `1.1.0` - New feature (DNS provider support)
 - `1.1.1` - Bug fix (GORM query fix)
@@ -1215,12 +1277,14 @@ go test ./integration/...
 ### Build Pipeline (Multi-Platform)
 
 **Platforms Supported:**
+
 - `linux/amd64`
 - `linux/arm64`
 
 **Build Process:**
 
 1. **Frontend Build:**
+
    ```bash
    cd frontend
    npm ci --only=production
@@ -1229,6 +1293,7 @@ go test ./integration/...
    ```
 
 2. **Backend Build:**
+
    ```bash
    cd backend
    go build -o charon cmd/api/main.go
@@ -1236,6 +1301,7 @@ go test ./integration/...
    ```
 
 3. **Docker Image Build:**
+
    ```bash
    docker buildx build \
      --platform linux/amd64,linux/arm64 \
@@ -1292,6 +1358,7 @@ go test ./integration/...
    - Level: SLSA Build L3 (hermetic builds)
 
 **Verification Example:**
+
 ```bash
 # Verify image signature
 cosign verify \
@@ -1309,6 +1376,7 @@ grype ghcr.io/wikid82/charon@sha256:<index-digest>
 ### Rollback Strategy
 
 **Container Rollback:**
+
 ```bash
 # List available versions
 docker images wikid82/charon
@@ -1319,6 +1387,7 @@ docker-compose up -d --pull always wikid82/charon:1.1.1
 ```
 
 **Database Rollback:**
+
 ```bash
 # Restore from backup
 docker exec charon /app/scripts/restore-backup.sh \
@@ -1355,11 +1424,13 @@ docker exec charon /app/scripts/restore-backup.sh \
 ### API Extensibility
 
 **REST API Design:**
+
 - Version prefix: `/api/v1/`
 - Future versions: `/api/v2/` (backward-compatible)
 - Deprecation policy: 2 major versions supported
 
 **WebHooks (Future):**
+
 - Event notifications for external systems
 - Triggers: Proxy host created, certificate renewed, security event
 - Payload: JSON with event type and data
@@ -1369,6 +1440,7 @@ docker exec charon /app/scripts/restore-backup.sh \
 **Current:** Cerberus security middleware injected into Caddy pipeline
 
 **Future:**
+
 - User-defined middleware (rate limiting rules, custom headers)
 - JavaScript/Lua scripting for request transformation
 - Plugin marketplace for community contributions
@@ -1452,6 +1524,7 @@ docker exec charon /app/scripts/restore-backup.sh \
 **GitHub Copilot Instructions:**
 
 All agents (`Planning`, `Backend_Dev`, `Frontend_Dev`, `DevOps`) must reference `ARCHITECTURE.md` when:
+
 - Creating new components
 - Modifying core systems
 - Changing integration points

CHANGELOG.md

@@ -9,6 +9,14 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Added
 
+- **Notifications:** Added Ntfy notification provider with support for self-hosted and cloud instances, optional Bearer token authentication, and JSON template customization
+
+- **Certificate Deletion**: Clean up expired and unused certificates directly from the Certificates page
+  - Expired Let's Encrypt certificates not attached to any proxy host can now be deleted
+  - Custom and staging certificates remain deletable when not in use
+  - In-use certificates show a disabled delete button with a tooltip explaining why
+  - Native browser confirmation replaced with an accessible, themed confirmation dialog
+
 - **Pushover Notification Provider**: Send push notifications to your devices via the Pushover app
   - Supports JSON templates (minimal, detailed, custom)
   - Application API Token stored securely — never exposed in API responses
@@ -24,16 +32,19 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   - See [Notification Guide](docs/features/notifications.md) for setup instructions
 
 ### CI/CD
+
 - **Supply Chain**: Optimized verification workflow to prevent redundant builds
   - Change: Removed direct Push/PR triggers; now waits for 'Docker Build' via `workflow_run`
 
 ### Security
+
 - **Supply Chain**: Enhanced PR verification workflow stability and accuracy
   - **Vulnerability Reporting**: Eliminated false negatives ("0 vulnerabilities") by enforcing strict failure conditions
   - **Tooling**: Switched to manual Grype installation ensuring usage of latest stable binary
   - **Observability**: Improved debugging visibility for vulnerability scans and SARIF generation
 
 ### Performance
+
 - **E2E Tests**: Reduced feature flag API calls by 90% through conditional polling optimization (Phase 2)
   - Conditional skip: Exits immediately if flags already in expected state (~50% of cases)
   - Request coalescing: Shares in-flight API requests between parallel test workers
@@ -45,6 +56,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   - Prevents timeout errors in Firefox/WebKit caused by strict label matching
 
 ### Fixed
+
+- **Notifications:** Fixed Pushover token-clearing bug where tokens were silently stripped on provider create/update
 - **TCP Monitor Creation**: Fixed misleading form UX that caused silent HTTP 500 errors when creating TCP monitors
   - Corrected URL placeholder to show `host:port` format instead of the incorrect `tcp://host:port` prefix
   - Added dynamic per-type placeholder and helper text (HTTP monitors show a full URL example; TCP monitors show `host:port`)
@@ -66,6 +79,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - **Test Performance**: Reduced system settings test execution time by 31% (from 23 minutes to 16 minutes)
 
 ### Changed
+
 - **Testing Infrastructure**: Enhanced E2E test helpers with better synchronization and error handling
 - **CI**: Optimized E2E workflow shards [Reduced from 4 to 3]
 

CONTRIBUTING.md

@@ -45,8 +45,6 @@ brew install lefthook
 go install github.com/evilmartians/lefthook@latest
 ```
 
-
-
 ```bash
 # Option 1: Homebrew (macOS/Linux)
 brew install golangci-lint
@@ -84,17 +82,20 @@ For local development, install go 1.26.0+ from [go.dev/dl](https://go.dev/dl/).
 When the project's Go version is updated (usually by Renovate):
 
 1. **Pull the latest changes**
+
    ```bash
    git pull
    ```
 
 2. **Update your local Go installation**
+
    ```bash
    # Run the Go update skill (downloads and installs the new version)
    .github/skills/scripts/skill-runner.sh utility-update-go-version
    ```
 
 3. **Rebuild your development tools**
+
    ```bash
    # This fixes lefthook hook errors and IDE issues
    ./scripts/rebuild-go-tools.sh

Dockerfile

@@ -43,7 +43,7 @@ ARG CADDY_CANDIDATE_VERSION=2.11.2
 ARG CADDY_USE_CANDIDATE=0
 ARG CADDY_PATCH_SCENARIO=B
 # renovate: datasource=go depName=github.com/greenpau/caddy-security
-ARG CADDY_SECURITY_VERSION=1.1.50
+ARG CADDY_SECURITY_VERSION=1.1.51
 # renovate: datasource=go depName=github.com/corazawaf/coraza-caddy
 ARG CORAZA_CADDY_VERSION=2.2.0
 ## When an official caddy image tag isn't available on the host, use a
@@ -458,7 +458,7 @@ SHELL ["/bin/ash", "-o", "pipefail", "-c"]
 # Note: In production, users should provide their own MaxMind license key
 # This uses the publicly available GeoLite2 database
 # In CI, timeout quickly rather than retrying to save build time
-ARG GEOLITE2_COUNTRY_SHA256=aa154fc6bcd712644de232a4abcdd07dac1f801308c0b6f93dbc2b375443da7b
+ARG GEOLITE2_COUNTRY_SHA256=f5e80a9a3129d46e75c8cccd66bfac725b0449a6c89ba5093a16561d58f20bda
 RUN mkdir -p /app/data/geoip && \
         if [ "$CI" = "true" ] || [ "$CI" = "1" ]; then \
             echo "⏱️  CI detected - quick download (10s timeout, no retries)"; \

README.md

@@ -94,6 +94,7 @@ services:
       retries: 3
       start_period: 40s
 ```
+
 > **Docker Socket Access:** Charon runs as a non-root user. If you mount the Docker socket for container discovery, the container needs permission to read it. Find your socket's group ID and add it to the compose file:
 >
 > ```bash
@@ -107,26 +108,34 @@ services:
 >       - "998"
 > ```
 
-### 2️⃣ Generate encryption key:
+### 2️⃣ Generate encryption key
+
 ```bash
 openssl rand -base64 32
 ```
-### 3️⃣ Start Charon:
+
+### 3️⃣ Start Charon
+
 ```bash
 docker-compose up -d
 ```
-### 4️⃣ Access the dashboard:
+
+### 4️⃣ Access the dashboard
+
 Open your browser and navigate to `http://localhost:8080` to access the dashboard and create your admin account.
+
 ```code
 http://localhost:8080
 ```
-### Getting Started:
-Full setup instructions and documentation are available at [https://wikid82.github.io/Charon/docs/getting-started.html](https://wikid82.github.io/Charon/docs/getting-started.html).
 
+### Getting Started
+
+Full setup instructions and documentation are available at [https://wikid82.github.io/Charon/docs/getting-started.html](https://wikid82.github.io/Charon/docs/getting-started.html).
 
 --- ## ✨ Top 10 Features
 
 ### 🎯 **Point & Click Management**
+
 No config files. No terminal commands. Just click, type your domain name, and you're live. If you can use a website, you can run Charon.
 
 ### 🔐 **Automatic HTTPS Certificates**
@@ -160,6 +169,7 @@ See exactly what's happening with live request logs, uptime monitoring, and inst
 ### 📥 **Migration Made Easy**
 
 Already invested in another reverse proxy? Bring your work with you by importing your existing configurations with one click:
+
 - **Caddyfile** — Migrate from other Caddy setups
 - **Nginx** — Import from Nginx based configurations (Coming Soon)
 - **Traefik** - Import from Traefik based configurations (Coming Soon)

SECURITY.md

@@ -27,46 +27,7 @@ public disclosure.
 
 ## Known Vulnerabilities
 
-### [CRITICAL] CVE-2025-68121 · Go Stdlib Critical in CrowdSec Bundled Binaries
-
-| Field        | Value |
-|--------------|-------|
-| **ID**       | CVE-2025-68121 (see also CHARON-2025-001) |
-| **Severity** | Critical |
-| **Status**   | Awaiting Upstream |
-
-**What**
-A critical Go standard library vulnerability affects CrowdSec binaries bundled in the Charon
-container image. The binaries were compiled against Go 1.25.6, which contains this flaw.
-Charon's own application code, compiled with Go 1.26.1, is unaffected.
-
-**Who**
-- Discovered by: Automated scan (Grype)
-- Reported: 2026-03-20
-- Affects: CrowdSec Agent component within the container; not directly exposed through Charon's
-  primary application interface
-
-**Where**
-- Component: CrowdSec Agent (bundled `cscli` and `crowdsec` binaries)
-- Versions affected: Charon container images with CrowdSec binaries compiled against Go < 1.25.7
-
-**When**
-- Discovered: 2026-03-20
-- Disclosed (if public): Not yet publicly disclosed
-- Target fix: When `golang:1.26.2-alpine` is published on Docker Hub
-
-**How**
-The vulnerability resides entirely within CrowdSec's compiled binary artifacts. Exploitation
-is limited to the CrowdSec agent's internal execution paths, which are not externally exposed
-through Charon's API or network interface.
-
-**Planned Remediation**
-`golang:1.26.2-alpine` is not yet available on Docker Hub. The `GO_VERSION` ARG has been
-reverted to `1.26.1` (the latest published image) until `1.26.2` is released. Once
-`golang:1.26.2-alpine` is available, bumping `GO_VERSION` to `1.26.2` and rebuilding the image
-will also resolve CVE-2026-25679 (High) and CVE-2025-61732 (High) tracked under CHARON-2025-001.
-
----
+Last reviewed: 2026-03-24
 
 ### [HIGH] CVE-2026-2673 · OpenSSL TLS 1.3 Key Exchange Group Downgrade
 
@@ -82,16 +43,19 @@ configuration includes the `DEFAULT` keyword, potentially allowing downgrade to
 suites. Affects Alpine 3.23.3 packages `libcrypto3` and `libssl3` at version 3.5.5-r0.
 
 **Who**
+
 - Discovered by: Automated scan (Grype)
 - Reported: 2026-03-20
 - Affects: Container runtime environment; Caddy reverse proxy TLS negotiation could be affected
   if default key group configuration is used
 
 **Where**
+
 - Component: Alpine 3.23.3 base image (`libcrypto3` 3.5.5-r0, `libssl3` 3.5.5-r0)
 - Versions affected: Alpine 3.23.3 prior to a patched `openssl` APK release
 
 **When**
+
 - Discovered: 2026-03-20
 - Disclosed (if public): 2026-03-13 (OpenSSL advisory)
 - Target fix: When Alpine Security publishes a patched `openssl` APK
@@ -103,19 +67,141 @@ does not use the `DEFAULT` keyword, which limits practical exploitability. The p
 present in the base image regardless of Caddy's configuration.
 
 **Planned Remediation**
-Monitor https://security.alpinelinux.org/vuln/CVE-2026-2673 for a patched Alpine APK. Once
+Monitor <https://security.alpinelinux.org/vuln/CVE-2026-2673> for a patched Alpine APK. Once
 available, update the pinned `ALPINE_IMAGE` digest in the Dockerfile, or add an explicit
 `RUN apk upgrade --no-cache libcrypto3 libssl3` to the runtime stage.
 
 ---
 
-### [HIGH] CHARON-2025-001 · CrowdSec Bundled Binaries — Go Stdlib CVEs
+### [MEDIUM] CVE-2025-60876 · BusyBox wget HTTP Request Smuggling
+
+| Field        | Value |
+|--------------|-------|
+| **ID**       | CVE-2025-60876 |
+| **Severity** | Medium · 6.5 |
+| **Status**   | Awaiting Upstream |
+
+**What**
+BusyBox wget through 1.37 accepts raw CR/LF and other C0 control bytes in the HTTP
+request-target, allowing request line splitting and header injection (CWE-284).
+
+**Who**
+
+- Discovered by: Automated scan (Grype)
+- Reported: 2026-03-24
+- Affects: Container runtime environment; Charon does not invoke busybox wget in application logic
+
+**Where**
+
+- Component: Alpine 3.23.3 base image (`busybox` 1.37.0-r30)
+- Versions affected: All Charon images using Alpine 3.23.3 with busybox < patched version
+
+**When**
+
+- Discovered: 2026-03-24
+- Disclosed (if public): Not yet publicly disclosed with fix
+- Target fix: When Alpine Security publishes a patched busybox APK
+
+**How**
+The vulnerable wget applet would need to be manually invoked inside the container with
+attacker-controlled URLs. Charon's application logic does not use busybox wget. EPSS score is
+0.00064 (0.20 percentile), indicating extremely low exploitation probability.
+
+**Planned Remediation**
+Monitor Alpine 3.23 for a patched busybox APK. No immediate action required. Practical risk to
+Charon users is negligible since the vulnerable code path is not exercised.
+
+---
+
+### [LOW] CVE-2026-26958 · edwards25519 MultiScalarMult Invalid Results
+
+| Field        | Value |
+|--------------|-------|
+| **ID**       | CVE-2026-26958 (GHSA-fw7p-63qq-7hpr) |
+| **Severity** | Low · 1.7 |
+| **Status**   | Awaiting Upstream |
+
+**What**
+`filippo.io/edwards25519` v1.1.0 `MultiScalarMult` produces invalid results or undefined
+behavior if the receiver is not the identity point. Fix available at v1.1.1 but requires
+CrowdSec to rebuild.
+
+**Who**
+
+- Discovered by: Automated scan (Grype)
+- Reported: 2026-03-24
+- Affects: CrowdSec Agent component within the container; not directly exposed through Charon's
+  primary application interface
+
+**Where**
+
+- Component: CrowdSec Agent (bundled `cscli` and `crowdsec` binaries)
+- Versions affected: CrowdSec builds using `filippo.io/edwards25519` < v1.1.1
+
+**When**
+
+- Discovered: 2026-03-24
+- Disclosed (if public): Public
+- Target fix: When CrowdSec releases a build with updated dependency
+
+**How**
+This is a rarely used advanced API within the edwards25519 library. CrowdSec does not directly
+expose MultiScalarMult to external input. EPSS score is 0.00018 (0.04 percentile).
+
+**Planned Remediation**
+Awaiting CrowdSec upstream release with updated dependency. No action available for Charon
+maintainers.
+
+---
+
+## Patched Vulnerabilities
+
+### ✅ [CRITICAL] CVE-2025-68121 · Go Stdlib Critical in CrowdSec Bundled Binaries
+
+| Field        | Value |
+|--------------|-------|
+| **ID**       | CVE-2025-68121 (see also CHARON-2025-001) |
+| **Severity** | Critical |
+| **Patched**  | 2026-03-24 |
+
+**What**
+A critical Go standard library vulnerability affects CrowdSec binaries bundled in the Charon
+container image. The binaries were compiled against Go 1.25.6, which contains this flaw.
+Charon's own application code, compiled with Go 1.26.1, is unaffected.
+
+**Who**
+
+- Discovered by: Automated scan (Grype)
+- Reported: 2026-03-20
+
+**Where**
+
+- Component: CrowdSec Agent (bundled `cscli` and `crowdsec` binaries)
+- Versions affected: Charon container images with CrowdSec binaries compiled against Go < 1.25.7
+
+**When**
+
+- Discovered: 2026-03-20
+- Patched: 2026-03-24
+- Time to patch: 4 days
+
+**How**
+The vulnerability resides entirely within CrowdSec's compiled binary artifacts. Exploitation
+is limited to the CrowdSec agent's internal execution paths, which are not externally exposed
+through Charon's API or network interface.
+
+**Resolution**
+CrowdSec binaries now compiled with Go 1.26.1 (was 1.25.6).
+
+---
+
+### ✅ [HIGH] CHARON-2025-001 · CrowdSec Bundled Binaries — Go Stdlib CVEs
 
 | Field        | Value |
 |--------------|-------|
 | **ID**       | CHARON-2025-001 (aliases: CVE-2025-58183, CVE-2025-58186, CVE-2025-58187, CVE-2025-61729, CVE-2026-25679, CVE-2025-61732, CVE-2026-27142, CVE-2026-27139) |
 | **Severity** | High · (preliminary, CVSS scores pending upstream confirmation) |
-| **Status**   | Awaiting Upstream |
+| **Patched**  | 2026-03-24 |
 
 **What**
 Multiple CVEs in Go standard library packages continue to accumulate in CrowdSec binaries bundled
@@ -126,40 +212,38 @@ tracked separately above). All issues resolve when CrowdSec is rebuilt against G
 Charon's own application code is unaffected.
 
 **Who**
+
 - Discovered by: Automated scan (Trivy, Grype)
 - Reported: 2025-12-01 (original cluster); expanded 2026-03-20
-- Affects: CrowdSec Agent component within the container; not directly exposed through Charon's
-  primary application interface
 
 **Where**
+
 - Component: CrowdSec Agent (bundled `cscli` and `crowdsec` binaries)
 - Versions affected: All Charon versions shipping CrowdSec binaries compiled against Go < 1.26.2
 
 **When**
+
 - Discovered: 2025-12-01
-- Disclosed (if public): Not yet publicly disclosed
-- Target fix: When `golang:1.26.2-alpine` is published on Docker Hub
+- Patched: 2026-03-24
+- Time to patch: 114 days
 
 **How**
 The CVEs reside entirely within CrowdSec's compiled binaries and cover HTTP/2, TLS, and archive
 processing paths that are not invoked by Charon's core application logic. The relevant network
 interfaces are not externally exposed via Charon's API surface.
 
-**Planned Remediation**
-`golang:1.26.2-alpine` is not yet available on Docker Hub. The `GO_VERSION` ARG has been
-reverted to `1.26.1` (the latest published image) until `1.26.2` is released. Once available,
-bumping `GO_VERSION` to `1.26.2` and rebuilding the image will resolve the entire alias cluster.
-CVE-2025-68121 (Critical severity, same root cause) is tracked separately above.
+**Resolution**
+CrowdSec binaries now compiled with Go 1.26.1.
 
 ---
 
-### [MEDIUM] CVE-2026-27171 · zlib CPU Exhaustion via Infinite Loop in CRC Combine Functions
+### ✅ [MEDIUM] CVE-2026-27171 · zlib CPU Exhaustion via Infinite Loop in CRC Combine Functions
 
 | Field        | Value |
 |--------------|-------|
 | **ID**       | CVE-2026-27171 |
 | **Severity** | Medium · 5.5 (NVD) / 2.9 (MITRE) |
-| **Status**   | Awaiting Upstream |
+| **Patched**  | 2026-03-24 |
 
 **What**
 zlib before 1.3.2 allows unbounded CPU consumption (denial of service) via the `crc32_combine64`
@@ -168,35 +252,31 @@ loop with no termination condition when given a specially crafted input, causing
 (CWE-1284).
 
 **Who**
+
 - Discovered by: 7aSecurity audit (commissioned by OSTIF)
 - Reported: 2026-02-17
-- Affects: Any component in the container that calls `crc32_combine`-family functions with
-  attacker-controlled input; not directly exposed through Charon's application interface
 
 **Where**
+
 - Component: Alpine 3.23.3 base image (`zlib` package, version 1.3.1-r2)
 - Versions affected: zlib < 1.3.2; all current Charon images using Alpine 3.23.3
 
 **When**
-- Discovered: 2026-02-17 (NVD published 2026-02-17)
-- Disclosed (if public): 2026-02-17
-- Target fix: When Alpine 3.23 publishes a patched `zlib` APK (requires zlib 1.3.2)
+
+- Discovered: 2026-02-17
+- Patched: 2026-03-24
+- Time to patch: 35 days
 
 **How**
 Exploitation requires local access (CVSS vector `AV:L`) and the ability to pass a crafted value
 to the `crc32_combine`-family functions. This code path is not invoked by Charon's reverse proxy
 or backend API. The vulnerability is non-blocking under the project's CI severity policy.
 
-**Planned Remediation**
-Monitor https://security.alpinelinux.org/vuln/CVE-2026-27171 for a patched Alpine APK. Once
-available, update the pinned `ALPINE_IMAGE` digest in the Dockerfile, or add an explicit
-`RUN apk upgrade --no-cache zlib` to the runtime stage. Remove the `.trivyignore` entry at
-that time.
+**Resolution**
+Alpine now ships zlib 1.3.2-r0 (fix threshold was 1.3.2).
 
 ---
 
-## Patched Vulnerabilities
-
 ### ✅ [HIGH] CHARON-2026-001 · Debian Base Image CVE Cluster
 
 | Field        | Value |
@@ -211,14 +291,17 @@ Seven HIGH-severity CVEs in Debian Trixie base image system libraries (`glibc`,
 available from the Debian Security Team.
 
 **Who**
+
 - Discovered by: Automated scan (Trivy)
 - Reported: 2026-02-04
 
 **Where**
+
 - Component: Debian Trixie base image (`libc6`, `libc-bin`, `libtasn1-6`, `libtiff`)
 - Versions affected: Charon container images built on Debian Trixie base (prior to Alpine migration)
 
 **When**
+
 - Discovered: 2026-02-04
 - Patched: 2026-03-20
 - Time to patch: 44 days
@@ -256,14 +339,17 @@ by CrowdSec for expression evaluation. Malicious regular expressions in CrowdSec
 parsers could cause CPU exhaustion and service degradation through exponential backtracking.
 
 **Who**
+
 - Discovered by: Automated scan (Trivy)
 - Reported: 2026-01-11
 
 **Where**
+
 - Component: CrowdSec (via `expr-lang/expr` dependency)
 - Versions affected: CrowdSec versions using `expr-lang/expr` < v1.17.7
 
 **When**
+
 - Discovered: 2026-01-11
 - Patched: 2026-01-11
 - Time to patch: 0 days
@@ -547,4 +633,4 @@ We recognize security researchers who help improve Charon:
 
 ---
 
-**Last Updated**: 2026-03-20
+**Last Updated**: 2026-03-24

VERSION.md

@@ -24,8 +24,10 @@ Example: `0.1.0-alpha`, `1.0.0-beta.1`, `2.0.0-rc.2`
 1. **Create and push a release tag**:
 
    ```bash
+
   git tag -a v1.0.0 -m "Release v1.0.0"
   git push origin v1.0.0
+
    ```
 
 2. **GitHub Actions automatically**:
@@ -51,10 +53,12 @@ Use it only when you need local/version-file parity checks:
   echo "1.0.0" > .version
    ```
 
-2. **Validate `.version` matches the latest tag**:
+1. **Validate `.version` matches the latest tag**:
 
    ```bash
+
   bash scripts/check-version-match-tag.sh
+
    ```
 
 ### Deterministic Rollout Verification Gates (Mandatory)

backend/go.mod

@@ -70,7 +70,7 @@ require (
 	github.com/opencontainers/go-digest v1.0.0 // indirect
 	github.com/opencontainers/image-spec v1.1.1 // indirect
 	github.com/oschwald/maxminddb-golang/v2 v2.1.1 // indirect
-	github.com/pelletier/go-toml/v2 v2.2.4 // indirect
+	github.com/pelletier/go-toml/v2 v2.3.0 // indirect
 	github.com/pkg/errors v0.9.1 // indirect
 	github.com/pmezard/go-difflib v1.0.0 // indirect
 	github.com/prometheus/client_model v0.6.2 // indirect

backend/go.sum

@@ -130,8 +130,8 @@ github.com/oschwald/geoip2-golang/v2 v2.1.0 h1:DjnLhNJu9WHwTrmoiQFvgmyJoczhdnm7L
 github.com/oschwald/geoip2-golang/v2 v2.1.0/go.mod h1:qdVmcPgrTJ4q2eP9tHq/yldMTdp2VMr33uVdFbHBiBc=
 github.com/oschwald/maxminddb-golang/v2 v2.1.1 h1:lA8FH0oOrM4u7mLvowq8IT6a3Q/qEnqRzLQn9eH5ojc=
 github.com/oschwald/maxminddb-golang/v2 v2.1.1/go.mod h1:PLdx6PR+siSIoXqqy7C7r3SB3KZnhxWr1Dp6g0Hacl8=
-github.com/pelletier/go-toml/v2 v2.2.4 h1:mye9XuhQ6gvn5h28+VilKrrPoQVanw5PMw/TB0t5Ec4=
-github.com/pelletier/go-toml/v2 v2.2.4/go.mod h1:2gIqNv+qfxSVS7cM2xJQKtLSTLUE9V8t9Stt+h56mCY=
+github.com/pelletier/go-toml/v2 v2.3.0 h1:k59bC/lIZREW0/iVaQR8nDHxVq8OVlIzYCOJf421CaM=
+github.com/pelletier/go-toml/v2 v2.3.0/go.mod h1:2gIqNv+qfxSVS7cM2xJQKtLSTLUE9V8t9Stt+h56mCY=
 github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=
 github.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
 github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=

backend/internal/api/handlers/auth_handler.go

@@ -126,11 +126,11 @@ func isLocalRequest(c *gin.Context) bool {
 }
 
 // setSecureCookie sets an auth cookie with security best practices
-// - HttpOnly: prevents JavaScript access (XSS protection)
-// - Secure: always true (all major browsers honour Secure on localhost HTTP;
-//   HTTP-on-private-IP without TLS is an unsupported deployment)
-// - SameSite: Lax for any local/private-network request (regardless of scheme),
-//   Strict otherwise (public HTTPS only)
+//   - HttpOnly: prevents JavaScript access (XSS protection)
+//   - Secure: always true (all major browsers honour Secure on localhost HTTP;
+//     HTTP-on-private-IP without TLS is an unsupported deployment)
+//   - SameSite: Lax for any local/private-network request (regardless of scheme),
+//     Strict otherwise (public HTTPS only)
 func setSecureCookie(c *gin.Context, name, value string, maxAge int) {
 	scheme := requestScheme(c)
 	sameSite := http.SameSiteStrictMode

backend/internal/api/handlers/certificate_handler_test.go

@@ -699,6 +699,124 @@ func TestDeleteCertificate_DiskSpaceCheckError(t *testing.T) {
 	}
 }
 
+// Test that an expired Let's Encrypt certificate not in use can be deleted.
+// The backend has no provider-based restrictions; deletion policy is frontend-only.
+func TestDeleteCertificate_ExpiredLetsEncrypt_NotInUse(t *testing.T) {
+	dbPath := t.TempDir() + "/cert_expired_le.db"
+	db, err := gorm.Open(sqlite.Open(fmt.Sprintf("file:%s?_journal_mode=WAL&_busy_timeout=5000&_foreign_keys=1", dbPath)), &gorm.Config{})
+	if err != nil {
+		t.Fatalf("failed to open db: %v", err)
+	}
+	sqlDB, err := db.DB()
+	if err != nil {
+		t.Fatalf("failed to access sql db: %v", err)
+	}
+	sqlDB.SetMaxOpenConns(1)
+	sqlDB.SetMaxIdleConns(1)
+
+	if err = db.AutoMigrate(&models.SSLCertificate{}, &models.ProxyHost{}); err != nil {
+		t.Fatalf("failed to migrate: %v", err)
+	}
+
+	expired := time.Now().Add(-24 * time.Hour)
+	cert := models.SSLCertificate{
+		UUID:      "expired-le-cert",
+		Name:      "expired-le",
+		Provider:  "letsencrypt",
+		Domains:   "expired.example.com",
+		ExpiresAt: &expired,
+	}
+	if err = db.Create(&cert).Error; err != nil {
+		t.Fatalf("failed to create cert: %v", err)
+	}
+
+	gin.SetMode(gin.TestMode)
+	r := gin.New()
+	r.Use(mockAuthMiddleware())
+	svc := services.NewCertificateService("/tmp", db)
+
+	mockBS := &mockBackupService{
+		createFunc: func() (string, error) {
+			return "backup-expired-le.tar.gz", nil
+		},
+	}
+
+	h := NewCertificateHandler(svc, mockBS, nil)
+	r.DELETE("/api/certificates/:id", h.Delete)
+
+	req := httptest.NewRequest(http.MethodDelete, "/api/certificates/"+toStr(cert.ID), http.NoBody)
+	w := httptest.NewRecorder()
+	r.ServeHTTP(w, req)
+
+	if w.Code != http.StatusOK {
+		t.Fatalf("expected 200 OK, got %d, body=%s", w.Code, w.Body.String())
+	}
+
+	var found models.SSLCertificate
+	if err = db.First(&found, cert.ID).Error; err == nil {
+		t.Fatal("expected expired LE certificate to be deleted")
+	}
+}
+
+// Test that a valid (non-expired) Let's Encrypt certificate not in use can be deleted.
+// Confirms the backend imposes no provider-based restrictions on deletion.
+func TestDeleteCertificate_ValidLetsEncrypt_NotInUse(t *testing.T) {
+	dbPath := t.TempDir() + "/cert_valid_le.db"
+	db, err := gorm.Open(sqlite.Open(fmt.Sprintf("file:%s?_journal_mode=WAL&_busy_timeout=5000&_foreign_keys=1", dbPath)), &gorm.Config{})
+	if err != nil {
+		t.Fatalf("failed to open db: %v", err)
+	}
+	sqlDB, err := db.DB()
+	if err != nil {
+		t.Fatalf("failed to access sql db: %v", err)
+	}
+	sqlDB.SetMaxOpenConns(1)
+	sqlDB.SetMaxIdleConns(1)
+
+	if err = db.AutoMigrate(&models.SSLCertificate{}, &models.ProxyHost{}); err != nil {
+		t.Fatalf("failed to migrate: %v", err)
+	}
+
+	future := time.Now().Add(30 * 24 * time.Hour)
+	cert := models.SSLCertificate{
+		UUID:      "valid-le-cert",
+		Name:      "valid-le",
+		Provider:  "letsencrypt",
+		Domains:   "valid.example.com",
+		ExpiresAt: &future,
+	}
+	if err = db.Create(&cert).Error; err != nil {
+		t.Fatalf("failed to create cert: %v", err)
+	}
+
+	gin.SetMode(gin.TestMode)
+	r := gin.New()
+	r.Use(mockAuthMiddleware())
+	svc := services.NewCertificateService("/tmp", db)
+
+	mockBS := &mockBackupService{
+		createFunc: func() (string, error) {
+			return "backup-valid-le.tar.gz", nil
+		},
+	}
+
+	h := NewCertificateHandler(svc, mockBS, nil)
+	r.DELETE("/api/certificates/:id", h.Delete)
+
+	req := httptest.NewRequest(http.MethodDelete, "/api/certificates/"+toStr(cert.ID), http.NoBody)
+	w := httptest.NewRecorder()
+	r.ServeHTTP(w, req)
+
+	if w.Code != http.StatusOK {
+		t.Fatalf("expected 200 OK, got %d, body=%s", w.Code, w.Body.String())
+	}
+
+	var found models.SSLCertificate
+	if err = db.First(&found, cert.ID).Error; err == nil {
+		t.Fatal("expected valid LE certificate to be deleted")
+	}
+}
+
 // Test Delete when IsCertificateInUse fails
 func TestDeleteCertificate_UsageCheckError(t *testing.T) {
 	db, err := gorm.Open(sqlite.Open(fmt.Sprintf("file:%s?mode=memory&cache=shared", t.Name())), &gorm.Config{})

backend/internal/api/handlers/notification_provider_handler.go

@@ -182,7 +182,7 @@ func (h *NotificationProviderHandler) Create(c *gin.Context) {
 	}
 
 	providerType := strings.ToLower(strings.TrimSpace(req.Type))
-	if providerType != "discord" && providerType != "gotify" && providerType != "webhook" && providerType != "email" && providerType != "telegram" && providerType != "slack" && providerType != "pushover" {
+	if providerType != "discord" && providerType != "gotify" && providerType != "webhook" && providerType != "email" && providerType != "telegram" && providerType != "slack" && providerType != "pushover" && providerType != "ntfy" {
 		respondSanitizedProviderError(c, http.StatusBadRequest, "UNSUPPORTED_PROVIDER_TYPE", "validation", "Unsupported notification provider type")
 		return
 	}
@@ -242,12 +242,12 @@ func (h *NotificationProviderHandler) Update(c *gin.Context) {
 	}
 
 	providerType := strings.ToLower(strings.TrimSpace(existing.Type))
-	if providerType != "discord" && providerType != "gotify" && providerType != "webhook" && providerType != "email" && providerType != "telegram" && providerType != "slack" && providerType != "pushover" {
+	if providerType != "discord" && providerType != "gotify" && providerType != "webhook" && providerType != "email" && providerType != "telegram" && providerType != "slack" && providerType != "pushover" && providerType != "ntfy" {
 		respondSanitizedProviderError(c, http.StatusBadRequest, "UNSUPPORTED_PROVIDER_TYPE", "validation", "Unsupported notification provider type")
 		return
 	}
 
-	if (providerType == "gotify" || providerType == "telegram" || providerType == "slack" || providerType == "pushover") && strings.TrimSpace(req.Token) == "" {
+	if (providerType == "gotify" || providerType == "telegram" || providerType == "slack" || providerType == "pushover" || providerType == "ntfy") && strings.TrimSpace(req.Token) == "" {
 		// Keep existing token if update payload omits token
 		req.Token = existing.Token
 	}

backend/internal/api/tests/user_smtp_audit_test.go

@@ -32,7 +32,9 @@ func hashForTest(t *testing.T, password string) string {
 	return string(h)
 }
 
-// setupAuditTestDB creates a clean in-memory database for each test
+// setupAuditTestDB creates a clean in-memory database for each test.
+// MaxOpenConns(1) is required: without it, GORM's pool can open multiple
+// connections to ":memory:", each receiving its own empty database.
 func setupAuditTestDB(t *testing.T) *gorm.DB {
 	t.Helper()
 	db, err := gorm.Open(sqlite.Open(":memory:"), &gorm.Config{
@@ -40,11 +42,23 @@ func setupAuditTestDB(t *testing.T) *gorm.DB {
 	})
 	require.NoError(t, err)
 
-	// Auto-migrate required models
+	sqlDB, err := db.DB()
+	require.NoError(t, err)
+	sqlDB.SetMaxOpenConns(1)
+	sqlDB.SetMaxIdleConns(1)
+
+	t.Cleanup(func() {
+		_ = sqlDB.Close()
+	})
+
+	// Auto-migrate required models (includes SecurityAudit so the
+	// background audit goroutine in SecurityService doesn't retry
+	// against a missing table).
 	err = db.AutoMigrate(
 		&models.User{},
 		&models.Setting{},
 		&models.ProxyHost{},
+		&models.SecurityAudit{},
 	)
 	require.NoError(t, err)
 	return db

backend/internal/models/ssl_certificate.go

@@ -10,7 +10,7 @@ type SSLCertificate struct {
 	ID          uint       `json:"-" gorm:"primaryKey"`
 	UUID        string     `json:"uuid" gorm:"uniqueIndex"`
 	Name        string     `json:"name" gorm:"index"`
-	Provider    string     `json:"provider" gorm:"index"`        // "letsencrypt", "custom", "self-signed"
+	Provider    string     `json:"provider" gorm:"index"`        // "letsencrypt", "letsencrypt-staging", "custom"
 	Domains     string     `json:"domains" gorm:"index"`         // comma-separated list of domains
 	Certificate string     `json:"certificate" gorm:"type:text"` // PEM-encoded certificate
 	PrivateKey  string     `json:"private_key" gorm:"type:text"` // PEM-encoded private key

backend/internal/notifications/feature_flags.go

@@ -9,5 +9,6 @@ const (
 	FlagTelegramServiceEnabled        = "feature.notifications.service.telegram.enabled"
 	FlagSlackServiceEnabled           = "feature.notifications.service.slack.enabled"
 	FlagPushoverServiceEnabled        = "feature.notifications.service.pushover.enabled"
+	FlagNtfyServiceEnabled            = "feature.notifications.service.ntfy.enabled"
 	FlagSecurityProviderEventsEnabled = "feature.notifications.security_provider_events.enabled"
 )

backend/internal/notifications/http_wrapper.go

@@ -458,10 +458,11 @@ func readCappedResponseBody(body io.Reader) ([]byte, error) {
 
 func sanitizeOutboundHeaders(headers map[string]string) map[string]string {
 	allowed := map[string]struct{}{
-		"content-type": {},
-		"user-agent":   {},
-		"x-request-id": {},
-		"x-gotify-key": {},
+		"content-type":  {},
+		"user-agent":    {},
+		"x-request-id":  {},
+		"x-gotify-key":  {},
+		"authorization": {},
 	}
 
 	sanitized := make(map[string]string)

backend/internal/notifications/http_wrapper_test.go

@@ -255,11 +255,11 @@ func TestSanitizeOutboundHeadersAllowlist(t *testing.T) {
 		"Cookie":        "sid=1",
 	})
 
-	if len(headers) != 4 {
-		t.Fatalf("expected 4 allowed headers, got %d", len(headers))
+	if len(headers) != 5 {
+		t.Fatalf("expected 5 allowed headers, got %d", len(headers))
 	}
-	if _, ok := headers["Authorization"]; ok {
-		t.Fatalf("authorization header must be stripped")
+	if _, ok := headers["Authorization"]; !ok {
+		t.Fatalf("authorization header must be allowed for ntfy Bearer auth")
 	}
 	if _, ok := headers["Cookie"]; ok {
 		t.Fatalf("cookie header must be stripped")

backend/internal/notifications/router.go

@@ -29,6 +29,8 @@ func (r *Router) ShouldUseNotify(providerType string, flags map[string]bool) boo
 		return flags[FlagSlackServiceEnabled]
 	case "pushover":
 		return flags[FlagPushoverServiceEnabled]
+	case "ntfy":
+		return flags[FlagNtfyServiceEnabled]
 	default:
 		return false
 	}

backend/internal/notifications/router_test.go

@@ -109,7 +109,7 @@ func TestRouter_ShouldUseNotify_PushoverServiceFlag(t *testing.T) {
 	router := NewRouter()
 
 	flags := map[string]bool{
-		FlagNotifyEngineEnabled:   true,
+		FlagNotifyEngineEnabled:    true,
 		FlagPushoverServiceEnabled: true,
 	}
 
@@ -122,3 +122,21 @@ func TestRouter_ShouldUseNotify_PushoverServiceFlag(t *testing.T) {
 		t.Fatalf("expected notify routing disabled for pushover when FlagPushoverServiceEnabled is false")
 	}
 }
+
+func TestRouter_ShouldUseNotify_NtfyServiceFlag(t *testing.T) {
+	router := NewRouter()
+
+	flags := map[string]bool{
+		FlagNotifyEngineEnabled: true,
+		FlagNtfyServiceEnabled:  true,
+	}
+
+	if !router.ShouldUseNotify("ntfy", flags) {
+		t.Fatalf("expected notify routing enabled for ntfy when FlagNtfyServiceEnabled is true")
+	}
+
+	flags[FlagNtfyServiceEnabled] = false
+	if router.ShouldUseNotify("ntfy", flags) {
+		t.Fatalf("expected notify routing disabled for ntfy when FlagNtfyServiceEnabled is false")
+	}
+}

backend/internal/services/notification_service.go

@@ -129,7 +129,7 @@ func validateDiscordProviderURL(providerType, rawURL string) error {
 // supportsJSONTemplates returns true if the provider type can use JSON templates
 func supportsJSONTemplates(providerType string) bool {
 	switch strings.ToLower(providerType) {
-	case "webhook", "discord", "gotify", "slack", "generic", "telegram", "pushover":
+	case "webhook", "discord", "gotify", "slack", "generic", "telegram", "pushover", "ntfy":
 		return true
 	default:
 		return false
@@ -138,7 +138,7 @@ func supportsJSONTemplates(providerType string) bool {
 
 func isSupportedNotificationProviderType(providerType string) bool {
 	switch strings.ToLower(strings.TrimSpace(providerType)) {
-	case "discord", "email", "gotify", "webhook", "telegram", "slack", "pushover":
+	case "discord", "email", "gotify", "webhook", "telegram", "slack", "pushover", "ntfy":
 		return true
 	default:
 		return false
@@ -161,6 +161,8 @@ func (s *NotificationService) isDispatchEnabled(providerType string) bool {
 		return s.getFeatureFlagValue(notifications.FlagSlackServiceEnabled, true)
 	case "pushover":
 		return s.getFeatureFlagValue(notifications.FlagPushoverServiceEnabled, true)
+	case "ntfy":
+		return s.getFeatureFlagValue(notifications.FlagNtfyServiceEnabled, true)
 	default:
 		return false
 	}
@@ -520,9 +522,13 @@ func (s *NotificationService) sendJSONPayload(ctx context.Context, p models.Noti
 				return fmt.Errorf("pushover emergency priority (2) requires retry and expire parameters; not yet supported")
 			}
 		}
+	case "ntfy":
+		if _, hasMessage := jsonPayload["message"]; !hasMessage {
+			return fmt.Errorf("ntfy payload must include a 'message' field")
+		}
 	}
 
-	if providerType == "gotify" || providerType == "webhook" || providerType == "telegram" || providerType == "slack" || providerType == "pushover" {
+	if providerType == "gotify" || providerType == "webhook" || providerType == "telegram" || providerType == "slack" || providerType == "pushover" || providerType == "ntfy" {
 		headers := map[string]string{
 			"Content-Type": "application/json",
 			"User-Agent":   "Charon-Notify/1.0",
@@ -579,6 +585,12 @@ func (s *NotificationService) sendJSONPayload(ctx context.Context, p models.Noti
 			dispatchURL = decryptedWebhookURL
 		}
 
+		if providerType == "ntfy" {
+			if strings.TrimSpace(p.Token) != "" {
+				headers["Authorization"] = "Bearer " + strings.TrimSpace(p.Token)
+			}
+		}
+
 		if providerType == "pushover" {
 			decryptedToken := p.Token
 			if strings.TrimSpace(decryptedToken) == "" {
@@ -847,7 +859,7 @@ func (s *NotificationService) CreateProvider(provider *models.NotificationProvid
 		}
 	}
 
-	if provider.Type != "gotify" && provider.Type != "telegram" && provider.Type != "slack" {
+	if provider.Type != "gotify" && provider.Type != "telegram" && provider.Type != "slack" && provider.Type != "ntfy" && provider.Type != "pushover" {
 		provider.Token = ""
 	}
 
@@ -883,7 +895,7 @@ func (s *NotificationService) UpdateProvider(provider *models.NotificationProvid
 		return err
 	}
 
-	if provider.Type == "gotify" || provider.Type == "telegram" || provider.Type == "slack" {
+	if provider.Type == "gotify" || provider.Type == "telegram" || provider.Type == "slack" || provider.Type == "ntfy" || provider.Type == "pushover" {
 		if strings.TrimSpace(provider.Token) == "" {
 			provider.Token = existing.Token
 		}

backend/internal/services/notification_service_json_test.go

@@ -661,3 +661,96 @@ func TestSendJSONPayload_Telegram_401ErrorMessage(t *testing.T) {
 	require.Error(t, sendErr)
 	assert.Contains(t, sendErr.Error(), "provider returned status 401")
 }
+
+func TestSendJSONPayload_Ntfy_Valid(t *testing.T) {
+	server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+		assert.Equal(t, "POST", r.Method)
+		assert.Equal(t, "application/json", r.Header.Get("Content-Type"))
+		assert.Empty(t, r.Header.Get("Authorization"), "no auth header when token is empty")
+
+		var payload map[string]any
+		err := json.NewDecoder(r.Body).Decode(&payload)
+		require.NoError(t, err)
+		assert.NotNil(t, payload["message"], "ntfy payload should have message field")
+
+		w.WriteHeader(http.StatusOK)
+	}))
+	defer server.Close()
+
+	db, err := gorm.Open(sqlite.Open("file::memory:"), &gorm.Config{})
+	require.NoError(t, err)
+
+	svc := NewNotificationService(db, nil)
+
+	provider := models.NotificationProvider{
+		Type:     "ntfy",
+		URL:      server.URL,
+		Template: "custom",
+		Config:   `{"message": {{toJSON .Message}}, "title": {{toJSON .Title}}}`,
+	}
+
+	data := map[string]any{
+		"Message": "Test notification",
+		"Title":   "Test",
+	}
+
+	err = svc.sendJSONPayload(context.Background(), provider, data)
+	assert.NoError(t, err)
+}
+
+func TestSendJSONPayload_Ntfy_WithToken(t *testing.T) {
+	server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+		assert.Equal(t, "Bearer tk_test123", r.Header.Get("Authorization"))
+
+		var payload map[string]any
+		err := json.NewDecoder(r.Body).Decode(&payload)
+		require.NoError(t, err)
+		assert.NotNil(t, payload["message"])
+
+		w.WriteHeader(http.StatusOK)
+	}))
+	defer server.Close()
+
+	db, err := gorm.Open(sqlite.Open("file::memory:"), &gorm.Config{})
+	require.NoError(t, err)
+
+	svc := NewNotificationService(db, nil)
+
+	provider := models.NotificationProvider{
+		Type:     "ntfy",
+		URL:      server.URL,
+		Token:    "tk_test123",
+		Template: "custom",
+		Config:   `{"message": {{toJSON .Message}}, "title": {{toJSON .Title}}}`,
+	}
+
+	data := map[string]any{
+		"Message": "Test notification",
+		"Title":   "Test",
+	}
+
+	err = svc.sendJSONPayload(context.Background(), provider, data)
+	assert.NoError(t, err)
+}
+
+func TestSendJSONPayload_Ntfy_MissingMessage(t *testing.T) {
+	db, err := gorm.Open(sqlite.Open("file::memory:"), &gorm.Config{})
+	require.NoError(t, err)
+
+	svc := NewNotificationService(db, nil)
+
+	provider := models.NotificationProvider{
+		Type:     "ntfy",
+		URL:      "http://localhost:9999",
+		Template: "custom",
+		Config:   `{"title": "Test"}`,
+	}
+
+	data := map[string]any{
+		"Message": "Test",
+	}
+
+	err = svc.sendJSONPayload(context.Background(), provider, data)
+	assert.Error(t, err)
+	assert.Contains(t, err.Error(), "ntfy payload must include a 'message' field")
+}

backend/internal/services/notification_service_test.go

@@ -3878,3 +3878,31 @@ func TestPushoverDispatch_DefaultBaseURL(t *testing.T) {
 	err := svc.sendJSONPayload(ctx, provider, data)
 	require.Error(t, err)
 }
+
+func TestIsSupportedNotificationProviderType_Ntfy(t *testing.T) {
+	assert.True(t, isSupportedNotificationProviderType("ntfy"))
+	assert.True(t, isSupportedNotificationProviderType("Ntfy"))
+	assert.True(t, isSupportedNotificationProviderType(" ntfy "))
+}
+
+func TestIsDispatchEnabled_NtfyDefaultTrue(t *testing.T) {
+	db := setupNotificationTestDB(t)
+	_ = db.AutoMigrate(&models.Setting{})
+	svc := NewNotificationService(db, nil)
+
+	assert.True(t, svc.isDispatchEnabled("ntfy"))
+}
+
+func TestIsDispatchEnabled_NtfyDisabledByFlag(t *testing.T) {
+	db := setupNotificationTestDB(t)
+	_ = db.AutoMigrate(&models.Setting{})
+	db.Create(&models.Setting{Key: "feature.notifications.service.ntfy.enabled", Value: "false"})
+	svc := NewNotificationService(db, nil)
+
+	assert.False(t, svc.isDispatchEnabled("ntfy"))
+}
+
+func TestSupportsJSONTemplates_Ntfy(t *testing.T) {
+	assert.True(t, supportsJSONTemplates("ntfy"))
+	assert.True(t, supportsJSONTemplates("Ntfy"))
+}

docs/SECURITY_PRACTICES.md

@@ -53,6 +53,7 @@ logger.Infof("API Key: %s", apiKey)
 ```
 
 Charon's masking rules:
+
 - Empty: `[empty]`
 - Short (< 16 chars): `[REDACTED]`
 - Normal (≥ 16 chars): `abcd...xyz9` (first 4 + last 4)
@@ -68,6 +69,7 @@ if !validateAPIKeyFormat(apiKey) {
 ```
 
 Requirements:
+
 - Length: 16-128 characters
 - Charset: Alphanumeric + underscore + hyphen
 - No spaces or special characters
@@ -99,6 +101,7 @@ Rotate secrets regularly:
 ### What to Log
 
 ✅ **Safe to log**:
+
 - Timestamps
 - User IDs (not usernames if PII)
 - IP addresses (consider GDPR implications)
@@ -108,6 +111,7 @@ Rotate secrets regularly:
 - Performance metrics
 
 ❌ **Never log**:
+
 - Passwords or password hashes
 - API keys or tokens (use masking)
 - Session IDs (full values)
@@ -139,6 +143,7 @@ logger.Infof("Login attempt: username=%s password=%s", username, password)
 ### Log Aggregation
 
 If using external log services (CloudWatch, Splunk, Datadog):
+
 - Ensure logs are encrypted in transit (TLS)
 - Ensure logs are encrypted at rest
 - Redact sensitive data before shipping
@@ -333,6 +338,7 @@ limiter := rate.NewLimiter(rate.Every(36*time.Second), 100)
 ```
 
 **Critical endpoints** (require stricter limits):
+
 - Login: 5 attempts per 15 minutes
 - Password reset: 3 attempts per hour
 - API key generation: 5 per day
@@ -369,6 +375,7 @@ return c.JSON(401, gin.H{"error": "invalid API key: abc123"})
 **Applicable if**: Processing data of EU residents
 
 **Requirements**:
+
 1. **Data minimization**: Collect only necessary data
 2. **Purpose limitation**: Use data only for stated purposes
 3. **Storage limitation**: Delete data when no longer needed
@@ -376,6 +383,7 @@ return c.JSON(401, gin.H{"error": "invalid API key: abc123"})
 5. **Breach notification**: Report breaches within 72 hours
 
 **Implementation**:
+
 - ✅ Charon masks API keys in logs (prevents exposure of personal data)
 - ✅ Secure file permissions (0600) protect sensitive data
 - ✅ Log retention policies prevent indefinite storage
@@ -390,12 +398,14 @@ return c.JSON(401, gin.H{"error": "invalid API key: abc123"})
 **Applicable if**: Processing, storing, or transmitting credit card data
 
 **Requirements**:
+
 1. **Requirement 3.4**: Render PAN unreadable (encryption, masking)
 2. **Requirement 8.2**: Strong authentication
 3. **Requirement 10.2**: Audit trails
 4. **Requirement 10.7**: Retain audit logs for 1 year
 
 **Implementation**:
+
 - ✅ Charon uses masking for sensitive credentials (same principle for PAN)
 - ✅ Secure file permissions align with access control requirements
 - ⚠️ Charon doesn't handle payment cards directly (delegated to payment processors)
@@ -409,12 +419,14 @@ return c.JSON(401, gin.H{"error": "invalid API key: abc123"})
 **Applicable if**: SaaS providers, cloud services
 
 **Trust Service Criteria**:
+
 1. **CC6.1**: Logical access controls (authentication, authorization)
 2. **CC6.6**: Encryption of data in transit
 3. **CC6.7**: Encryption of data at rest
 4. **CC7.2**: Monitoring and detection (logging, alerting)
 
 **Implementation**:
+
 - ✅ API key validation ensures strong credentials (CC6.1)
 - ✅ File permissions (0600) protect data at rest (CC6.7)
 - ✅ Masked logging enables monitoring without exposing secrets (CC7.2)
@@ -429,12 +441,14 @@ return c.JSON(401, gin.H{"error": "invalid API key: abc123"})
 **Applicable to**: Any organization implementing ISMS
 
 **Key Controls**:
+
 1. **A.9.4.3**: Password management systems
 2. **A.10.1.1**: Cryptographic controls
 3. **A.12.4.1**: Event logging
 4. **A.18.1.5**: Protection of personal data
 
 **Implementation**:
+
 - ✅ API key format validation (minimum 16 chars, charset restrictions)
 - ✅ Key rotation procedures documented
 - ✅ Secure storage with file permissions (0600)
@@ -491,6 +505,7 @@ grep -i "api[_-]key\|token\|password" playwright-report/index.html
 **Recommended schedule**: Annual or after major releases
 
 **Focus areas**:
+
 1. Authentication bypass
 2. Authorization vulnerabilities
 3. SQL injection

docs/actions/trivy-scan-failure.md

@@ -1,6 +1,6 @@
 **Status**: ✅ RESOLVED (January 30, 2026)
 
-https://github.com/Wikid82/Charon/actions/runs/21503634925/job/61955008214
+<https://github.com/Wikid82/Charon/actions/runs/21503634925/job/61955008214>
 
 Run # Normalize image name for reference
 🔍 Extracting binary from: ghcr.io/wikid82/charon:feature/beta-release
@@ -27,6 +27,7 @@ Add a check to ensure steps.pr-info.outputs.pr_number is set before constructing
 Suggested code improvement for the “Extract charon binary from container” step:
 
 YAML
+
 - name: Extract charon binary from container
   if: steps.check-artifact.outputs.artifact_exists == 'true'
   id: extract
@@ -44,6 +45,7 @@ YAML
     echo "🔍 Extracting binary from: ${IMAGE_REF}"
     ...
 This ensures the workflow does not attempt to use an invalid image tag when the PR number is missing. Adjust similar logic throughout the workflow to handle missing variables gracefully.
+
 ## Resolution
 
 Fixed by adding proper validation for PR number before constructing Docker image reference, ensuring IMAGE_REF is never constructed with empty/missing variables. Branch name sanitization also implemented to handle slashes in feature branch names.

docs/analysis/crowdsec_integration_failure_analysis.md

@@ -2,7 +2,7 @@
 
 **Date:** 2026-01-28
 **PR:** #550 - Alpine to Debian Trixie Migration
-**CI Run:** https://github.com/Wikid82/Charon/actions/runs/21456678628/job/61799104804
+**CI Run:** <https://github.com/Wikid82/Charon/actions/runs/21456678628/job/61799104804>
 **Branch:** feature/beta-release
 
 ---
@@ -18,16 +18,19 @@ The CrowdSec integration tests are failing after migrating the Dockerfile from A
 ### 1. **CrowdSec Builder Stage Compatibility**
 
 **Alpine vs Debian Differences:**
+
 - **Alpine** uses `musl libc`, **Debian** uses `glibc`
 - Different package managers: `apk` (Alpine) vs `apt` (Debian)
 - Different package names and availability
 
 **Current Dockerfile (lines 218-270):**
+
 ```dockerfile
 FROM --platform=$BUILDPLATFORM golang:1.25.7-trixie AS crowdsec-builder
 ```
 
 **Dependencies Installed:**
+
 ```dockerfile
 RUN apt-get update && apt-get install -y --no-install-recommends \
     git clang lld \
@@ -36,6 +39,7 @@ RUN xx-apt install -y gcc libc6-dev
 ```
 
 **Possible Issues:**
+
 - **Missing build dependencies**: CrowdSec might require additional packages on Debian that were implicitly available on Alpine
 - **Git clone failures**: Network issues or GitHub rate limiting
 - **Dependency resolution**: `go mod tidy` might behave differently
@@ -44,6 +48,7 @@ RUN xx-apt install -y gcc libc6-dev
 ### 2. **CrowdSec Binary Path Issues**
 
 **Runtime Image (lines 359-365):**
+
 ```dockerfile
 # Copy CrowdSec binaries from the crowdsec-builder stage (built with Go 1.25.5+)
 COPY --from=crowdsec-builder /crowdsec-out/crowdsec /usr/local/bin/crowdsec
@@ -52,17 +57,20 @@ COPY --from=crowdsec-builder /crowdsec-out/config /etc/crowdsec.dist
 ```
 
 **Possible Issues:**
+
 - If the builder stage fails, these COPY commands will fail
 - If fallback stage is used (for non-amd64), paths might be wrong
 
 ### 3. **CrowdSec Configuration Issues**
 
 **Entrypoint Script CrowdSec Init (docker-entrypoint.sh):**
+
 - Symlink creation from `/etc/crowdsec` to `/app/data/crowdsec/config`
 - Configuration file generation and substitution
 - Hub index updates
 
 **Possible Issues:**
+
 - Symlink already exists as directory instead of symlink
 - Permission issues with non-root user
 - Configuration templates missing or incompatible
@@ -70,12 +78,14 @@ COPY --from=crowdsec-builder /crowdsec-out/config /etc/crowdsec.dist
 ### 4. **Test Script Environment Issues**
 
 **Integration Test (crowdsec_integration.sh):**
+
 - Builds the image with `docker build -t charon:local .`
 - Starts container and waits for API
 - Tests CrowdSec Hub connectivity
 - Tests preset pull/apply functionality
 
 **Possible Issues:**
+
 - Build step timing out or failing silently
 - Container failing to start properly
 - CrowdSec processes not starting
@@ -88,6 +98,7 @@ COPY --from=crowdsec-builder /crowdsec-out/config /etc/crowdsec.dist
 ### Step 1: Check Build Logs
 
 Review the CI build logs for the CrowdSec builder stage:
+
 - Look for `git clone` errors
 - Check for `go get` or `go mod tidy` failures
 - Verify `xx-go build` completes successfully
@@ -96,6 +107,7 @@ Review the CI build logs for the CrowdSec builder stage:
 ### Step 2: Verify CrowdSec Binaries
 
 Check if CrowdSec binaries are actually present:
+
 ```bash
 docker run --rm charon:local which crowdsec
 docker run --rm charon:local which cscli
@@ -105,6 +117,7 @@ docker run --rm charon:local cscli version
 ### Step 3: Check CrowdSec Configuration
 
 Verify configuration is properly initialized:
+
 ```bash
 docker run --rm charon:local ls -la /etc/crowdsec
 docker run --rm charon:local ls -la /app/data/crowdsec
@@ -114,6 +127,7 @@ docker run --rm charon:local cat /etc/crowdsec/config.yaml
 ### Step 4: Test CrowdSec Locally
 
 Run the integration test locally:
+
 ```bash
 # Build image
 docker build --no-cache -t charon:local .
@@ -129,6 +143,7 @@ docker build --no-cache -t charon:local .
 ### Fix 1: Add Missing Build Dependencies
 
 If the build is failing due to missing dependencies, add them to the CrowdSec builder:
+
 ```dockerfile
 RUN apt-get update && apt-get install -y --no-install-recommends \
     git clang lld \
@@ -139,6 +154,7 @@ RUN apt-get update && apt-get install -y --no-install-recommends \
 ### Fix 2: Add Build Stage Debugging
 
 Add debugging output to identify where the build fails:
+
 ```dockerfile
 # After git clone
 RUN echo "CrowdSec source cloned successfully" && ls -la
@@ -153,6 +169,7 @@ RUN echo "Build complete" && ls -la /crowdsec-out/
 ### Fix 3: Use CrowdSec Fallback
 
 If the build continues to fail, ensure the fallback stage is working:
+
 ```dockerfile
 # In final stage, use conditional COPY
 COPY --from=crowdsec-fallback /crowdsec-out/bin/crowdsec /usr/local/bin/crowdsec || \
@@ -162,6 +179,7 @@ COPY --from=crowdsec-builder /crowdsec-out/crowdsec /usr/local/bin/crowdsec
 ### Fix 4: Verify cscli Before Test
 
 Add a verification step in the entrypoint:
+
 ```bash
 if ! command -v cscli >/dev/null; then
     echo "ERROR: CrowdSec not installed properly"

docs/decisions/sprint1-timeout-remediation-findings.md

@@ -11,11 +11,13 @@
 **File**: `tests/settings/system-settings.spec.ts`
 
 **Changes Made**:
+
 1. **Removed** `waitForFeatureFlagPropagation()` call from `beforeEach` hook (lines 35-46)
    - This was causing 10s × 31 tests = 310s of polling overhead per shard
    - Commented out with clear explanation linking to remediation plan
 
 2. **Added** `test.afterEach()` hook with direct API state restoration:
+
    ```typescript
    test.afterEach(async ({ page }) => {
      await test.step('Restore default feature flag state', async () => {
@@ -34,12 +36,14 @@
    ```
 
 **Rationale**:
+
 - Tests already verify feature flag state individually after toggle actions
 - Initial state verification in beforeEach was redundant
 - Explicit cleanup in afterEach ensures test isolation without polling overhead
 - Direct API mutation for state restoration is faster than polling
 
 **Expected Impact**:
+
 - 310s saved per shard (10s × 31 tests)
 - Elimination of inter-test dependencies
 - No state leakage between tests
@@ -51,12 +55,14 @@
 **Changes Made**:
 
 1. **Added module-level cache** for in-flight requests:
+
    ```typescript
    // Cache for in-flight requests (per-worker isolation)
    const inflightRequests = new Map<string, Promise<Record<string, boolean>>>();
    ```
 
 2. **Implemented cache key generation** with sorted keys and worker isolation:
+
    ```typescript
    function generateCacheKey(
      expectedFlags: Record<string, boolean>,
@@ -81,6 +87,7 @@
    - Removes promise from cache after completion (success or failure)
 
 4. **Added cleanup function**:
+
    ```typescript
    export function clearFeatureFlagCache(): void {
      inflightRequests.clear();
@@ -89,16 +96,19 @@
    ```
 
 **Why Sorted Keys?**
+
 - `{a:true, b:false}` vs `{b:false, a:true}` are semantically identical
 - Without sorting, they generate different cache keys → cache misses
 - Sorting ensures consistent key regardless of property order
 
 **Why Worker Isolation?**
+
 - Playwright workers run in parallel across different browser contexts
 - Each worker needs its own cache to avoid state conflicts
 - Worker index provides unique namespace per parallel process
 
 **Expected Impact**:
+
 - 30-40% reduction in duplicate API calls (revised from original 70-80% estimate)
 - Cache hit rate should be >30% based on similar flag state checks
 - Reduced API server load during parallel test execution
@@ -108,21 +118,26 @@
 **Status**: Partially Investigated
 
 **Issue**:
+
 - Test: `tests/dns-provider-types.spec.ts` (line 260)
 - Symptom: Label locator `/script.*path/i` passes in Chromium, fails in Firefox/WebKit
 - Test code:
+
   ```typescript
   const scriptField = page.getByLabel(/script.*path/i);
   await expect(scriptField).toBeVisible({ timeout: 10000 });
   ```
 
 **Investigation Steps Completed**:
+
 1. ✅ Confirmed E2E environment is running and healthy
 2. ✅ Attempted to run DNS provider type tests in Chromium
 3. ⏸️ Further investigation deferred due to test execution issues
 
 **Investigation Steps Remaining** (per spec):
+
 1. Run with Playwright Inspector to compare accessibility trees:
+
    ```bash
    npx playwright test tests/dns-provider-types.spec.ts --project=chromium --headed --debug
    npx playwright test tests/dns-provider-types.spec.ts --project=firefox --headed --debug
@@ -137,6 +152,7 @@
 5. If not fixable: Use the helper function approach from Phase 2
 
 **Recommendation**:
+
 - Complete investigation in separate session with headed browser mode
 - DO NOT add `.or()` chains unless investigation proves it's necessary
 - Create formal Decision Record once root cause is identified
@@ -144,31 +160,37 @@
 ## Validation Checkpoints
 
 ### Checkpoint 1: Execution Time
+
 **Status**: ⏸️ In Progress
 
 **Target**: <15 minutes (900s) for full test suite
 
 **Command**:
+
 ```bash
 time npx playwright test tests/settings/system-settings.spec.ts --project=chromium
 ```
 
 **Results**:
+
 - Test execution interrupted during validation
 - Observed: Tests were picking up multiple spec files from security/ folder
 - Need to investigate test file patterns or run with more specific filtering
 
 **Action Required**:
+
 - Re-run with corrected test file path or filtering
 - Ensure only system-settings tests are executed
 - Measure execution time and compare to baseline
 
 ### Checkpoint 2: Test Isolation
+
 **Status**: ⏳ Pending
 
 **Target**: All tests pass with `--repeat-each=5 --workers=4`
 
 **Command**:
+
 ```bash
 npx playwright test tests/settings/system-settings.spec.ts --project=chromium --repeat-each=5 --workers=4
 ```
@@ -176,11 +198,13 @@ npx playwright test tests/settings/system-settings.spec.ts --project=chromium --
 **Status**: Not executed yet
 
 ### Checkpoint 3: Cross-browser
+
 **Status**: ⏳ Pending
 
 **Target**: Firefox/WebKit pass rate >85%
 
 **Command**:
+
 ```bash
 npx playwright test tests/settings/system-settings.spec.ts --project=firefox --project=webkit
 ```
@@ -188,11 +212,13 @@ npx playwright test tests/settings/system-settings.spec.ts --project=firefox --p
 **Status**: Not executed yet
 
 ### Checkpoint 4: DNS provider tests (secondary issue)
+
 **Status**: ⏳ Pending
 
 **Target**: Firefox tests pass or investigation complete
 
 **Command**:
+
 ```bash
 npx playwright test tests/dns-provider-types.spec.ts --project=firefox
 ```
@@ -204,11 +230,13 @@ npx playwright test tests/dns-provider-types.spec.ts --project=firefox
 ### Decision: Use Direct API Mutation for State Restoration
 
 **Context**:
+
 - Tests need to restore default feature flag state after modifications
 - Original approach used polling-based verification in beforeEach
 - Alternative approaches: polling in afterEach vs direct API mutation
 
 **Options Evaluated**:
+
 1. **Polling in afterEach** - Verify state propagated after mutation
    - Pros: Confirms state is actually restored
    - Cons: Adds 500ms-2s per test (polling overhead)
@@ -219,12 +247,14 @@ npx playwright test tests/dns-provider-types.spec.ts --project=firefox
    - Why chosen: Feature flag updates are synchronous in backend
 
 **Rationale**:
+
 - Feature flag updates via PUT /api/v1/feature-flags are processed synchronously
 - Database write is immediate (SQLite WAL mode)
 - No async propagation delay in single-process test environment
 - Subsequent tests will verify state on first read, catching any issues
 
 **Impact**:
+
 - Test runtime reduced by 15-60s per test file (31 tests × 500ms-2s polling)
 - Risk: If state restoration fails, next test will fail loudly (detectable)
 - Acceptable trade-off for 10-20% execution time improvement
@@ -234,15 +264,18 @@ npx playwright test tests/dns-provider-types.spec.ts --project=firefox
 ### Decision: Cache Key Sorting for Semantic Equality
 
 **Context**:
+
 - Multiple tests may check the same feature flag state but with different property order
 - Without normalization, `{a:true, b:false}` and `{b:false, a:true}` generate different keys
 
 **Rationale**:
+
 - JavaScript objects have insertion order, but semantically these are identical states
 - Sorting keys ensures cache hits for semantically identical flag states
 - Minimal performance cost (~1ms for sorting 3-5 keys)
 
 **Impact**:
+
 - Estimated 10-15% cache hit rate improvement
 - No downside - pure optimization
 

docs/development/go_version_upgrades.md

@@ -78,6 +78,7 @@ git pull origin development
 ```
 
 This script:
+
 - Detects the required Go version from `go.work`
 - Downloads it from golang.org
 - Installs it to `~/sdk/go{version}/`
@@ -103,6 +104,7 @@ Even if you used Option A (which rebuilds automatically), you can always manuall
 ```
 
 This rebuilds:
+
 - **golangci-lint** — Pre-commit linter (critical)
 - **gopls** — IDE language server (critical)
 - **govulncheck** — Security scanner
@@ -132,11 +134,13 @@ Current Go version: go version go1.26.0 linux/amd64
 Your IDE caches the old Go language server (gopls). Reload to use the new one:
 
 **VS Code:**
+
 - Press `Cmd/Ctrl+Shift+P`
 - Type "Developer: Reload Window"
 - Press Enter
 
 **GoLand or IntelliJ IDEA:**
+
 - File → Invalidate Caches → Restart
 - Wait for indexing to complete
 
@@ -243,6 +247,7 @@ go install golang.org/x/tools/gopls@latest
 ### How often do Go versions change?
 
 Go releases **two major versions per year**:
+
 - February (e.g., Go 1.26.0)
 - August (e.g., Go 1.27.0)
 
@@ -255,6 +260,7 @@ Plus occasional patch releases (e.g., Go 1.26.1) for security fixes.
 **Usually no**, but it doesn't hurt. Patch releases (like 1.26.0 → 1.26.1) rarely break tool compatibility.
 
 **Rebuild if:**
+
 - Pre-commit hooks start failing
 - IDE shows unexpected errors
 - Tools report version mismatches
@@ -262,6 +268,7 @@ Plus occasional patch releases (e.g., Go 1.26.1) for security fixes.
 ### Why don't CI builds have this problem?
 
 CI environments are **ephemeral** (temporary). Every workflow run:
+
 1. Starts with a fresh container
 2. Installs Go from scratch
 3. Installs tools from scratch
@@ -295,12 +302,14 @@ But for Charon development, you only need **one version** (whatever's in `go.wor
 **Short answer:** Your local tools will be out of sync, but CI will still work.
 
 **What breaks:**
+
 - Pre-commit hooks fail (but will auto-rebuild)
 - IDE shows phantom errors
 - Manual `go test` might fail locally
 - CI is unaffected (it always uses the correct version)
 
 **When to catch up:**
+
 - Before opening a PR (CI checks will fail if your code uses old Go features)
 - When local development becomes annoying
 
@@ -326,6 +335,7 @@ But they only take ~400MB each, so cleanup is optional.
 Renovate updates **Dockerfile** and **go.work**, but it can't update tools on *your* machine.
 
 **Think of it like this:**
+
 - Renovate: "Hey team, we're now using Go 1.26.0"
 - Your machine: "Cool, but my tools are still Go 1.25.6. Let me rebuild them."
 
@@ -334,18 +344,22 @@ The rebuild script bridges that gap.
 ### What's the difference between `go.work`, `go.mod`, and my system Go?
 
 **`go.work`** — Workspace file (multi-module projects like Charon)
+
 - Specifies minimum Go version for the entire project
 - Used by Renovate to track upgrades
 
 **`go.mod`** — Module file (individual Go modules)
+
 - Each module (backend, tools) has its own `go.mod`
 - Inherits Go version from `go.work`
 
 **System Go** (`go version`) — What's installed on your machine
+
 - Must be >= the version in `go.work`
 - Tools are compiled with whatever version this is
 
 **Example:**
+
 ```
 go.work says: "Use Go 1.26.0 or newer"
 go.mod says: "I'm part of the workspace, use its Go version"
@@ -364,12 +378,14 @@ Charon's pre-commit hook automatically detects and fixes tool version mismatches
 **How it works:**
 
 1. **Check versions:**
+
    ```bash
    golangci-lint version → "built with go1.25.6"
    go version → "go version go1.26.0"
    ```
 
 2. **Detect mismatch:**
+
    ```
    ⚠️  golangci-lint Go version mismatch:
       golangci-lint: 1.25.6
@@ -377,6 +393,7 @@ Charon's pre-commit hook automatically detects and fixes tool version mismatches
    ```
 
 3. **Auto-rebuild:**
+
    ```
    🔧 Rebuilding golangci-lint with current Go version...
    ✅ golangci-lint rebuilt successfully
@@ -406,11 +423,13 @@ If you want manual control, edit `scripts/pre-commit-hooks/golangci-lint-fast.sh
 ## Need Help?
 
 **Open a [Discussion](https://github.com/Wikid82/charon/discussions)** if:
+
 - These instructions didn't work for you
 - You're seeing errors not covered in troubleshooting
 - You have suggestions for improving this guide
 
 **Open an [Issue](https://github.com/Wikid82/charon/issues)** if:
+
 - The rebuild script crashes
 - Pre-commit auto-rebuild isn't working
 - CI is failing for Go version reasons

docs/development/running-e2e.md

@@ -3,16 +3,20 @@
 This document explains how to run Playwright tests using a real browser (headed) on Linux machines and in the project's Docker E2E environment.
 
 ## Key points
+
 - Playwright's interactive Test UI (--ui) requires an X server (a display). On headless CI or servers, use Xvfb.
 - Prefer the project's E2E Docker image for integration-like runs; use the local `--ui` flow for manual debugging.
 
 ## Quick commands (local Linux)
+
 - Headless (recommended for CI / fast runs):
+
   ```bash
   npm run e2e
   ```
 
 - Headed UI on a headless machine (auto-starts Xvfb):
+
   ```bash
   npm run e2e:ui:headless-server
   # or, if you prefer manual control:
@@ -20,37 +24,46 @@ This document explains how to run Playwright tests using a real browser (headed)
   ```
 
 - Headed UI on a workstation with an X server already running:
+
   ```bash
   npx playwright test --ui
   ```
 
 - Open the running Docker E2E app in your system browser (one-step via VS Code task):
   - Run the VS Code task: **Open: App in System Browser (Docker E2E)**
-  - This will rebuild the E2E container (if needed), wait for http://localhost:8080 to respond, and open your system browser automatically.
+  - This will rebuild the E2E container (if needed), wait for <http://localhost:8080> to respond, and open your system browser automatically.
 
 - Open the running Docker E2E app in VS Code Simple Browser:
   - Run the VS Code task: **Open: App in Simple Browser (Docker E2E)**
   - Then use the command palette: `Simple Browser: Open URL` → paste `http://localhost:8080`
 
 ## Using the project's E2E Docker image (recommended for parity with CI)
+
 1. Rebuild/start the E2E container (this sets up the full test environment):
+
    ```bash
    .github/skills/scripts/skill-runner.sh docker-rebuild-e2e
    ```
+
   If you need a clean rebuild after integration alignment changes:
+
   ```bash
   .github/skills/scripts/skill-runner.sh docker-rebuild-e2e --clean --no-cache
   ```
-2. Run the UI against the container (you still need an X server on your host):
+
+1. Run the UI against the container (you still need an X server on your host):
+
    ```bash
    PLAYWRIGHT_BASE_URL=http://localhost:8080 npm run e2e:ui:headless-server
    ```
 
 ## CI guidance
+
 - Do not run Playwright `--ui` in CI. Use headless runs or the E2E Docker image and collect traces/videos for failures.
 - For coverage, use the provided skill: `.github/skills/scripts/skill-runner.sh test-e2e-playwright-coverage`
 
 ## Troubleshooting
+
 - Playwright error: "Looks like you launched a headed browser without having a XServer running." → run `npm run e2e:ui:headless-server` or install Xvfb.
 - If `npm run e2e:ui:headless-server` fails with an exit code like `148`:
   - Inspect Xvfb logs: `tail -n 200 /tmp/xvfb.playwright.log`
@@ -59,11 +72,13 @@ This document explains how to run Playwright tests using a real browser (headed)
 - If running inside Docker, prefer the skill-runner which provisions the required services; the UI still needs host X (or use VNC).
 
 ## Developer notes (what we changed)
+
 - Added `scripts/run-e2e-ui.sh` — wrapper that auto-starts Xvfb when DISPLAY is unset.
 - Added `npm run e2e:ui:headless-server` to run the Playwright UI on headless machines.
 - Playwright config now auto-starts Xvfb when `--ui` is requested locally and prints an actionable error if Xvfb is not available.
 
 ## Security & hygiene
+
 - Playwright auth artifacts are ignored by git (`playwright/.auth/`). Do not commit credentials.
 
 ---

docs/features.md

@@ -237,7 +237,7 @@ Watch requests flow through your proxy in real-time. Filter by domain, status co
 
 ### 🔔 Notifications
 
-Get alerted when it matters. Charon notifications now run through the Notify HTTP wrapper with support for Discord, Gotify, and Custom Webhook providers. Payload-focused test coverage is included to help catch formatting and delivery regressions before release.
+Get alerted when it matters. Charon sends notifications through Discord, Gotify, Ntfy, Pushover, Slack, Email, and Custom Webhook providers. Choose a built-in JSON template or write your own to control exactly what your alerts look like.
 
 → [Learn More](features/notifications.md)
 

docs/features/api.md

@@ -23,6 +23,7 @@ Authorization: Bearer your-api-token-here
 ```
 
 Tokens support granular permissions:
+
 - **Read-only**: View configurations without modification
 - **Full access**: Complete CRUD operations
 - **Scoped**: Limit to specific resource types

docs/features/caddyfile-import.md

@@ -52,6 +52,7 @@ Caddyfile import parses your existing Caddy configuration files and converts the
 Choose one of three methods:
 
 **Paste Content:**
+
 ```
 example.com {
     reverse_proxy localhost:3000
@@ -63,10 +64,12 @@ api.example.com {
 ```
 
 **Upload File:**
+
 - Click **Choose File**
 - Select your Caddyfile
 
 **Fetch from URL:**
+
 - Enter URL to raw Caddyfile content
 - Useful for version-controlled configurations
 

docs/features/dns-challenge.md

@@ -447,6 +447,7 @@ Charon displays instructions to remove the TXT record after certificate issuance
 **Symptom**: Certificate request stuck at "Waiting for Propagation" or validation fails.
 
 **Causes**:
+
 - DNS TTL is high (cached old records)
 - DNS provider has slow propagation
 - Regional DNS inconsistency
@@ -497,6 +498,7 @@ Charon displays instructions to remove the TXT record after certificate issuance
 **Symptom**: Connection test passes, but record creation fails.
 
 **Causes**:
+
 - API token has read-only permissions
 - Zone/domain not accessible with current credentials
 - Rate limiting or account restrictions
@@ -513,6 +515,7 @@ Charon displays instructions to remove the TXT record after certificate issuance
 **Symptom**: "Record already exists" error during certificate request.
 
 **Causes**:
+
 - Previous challenge attempt left orphaned record
 - Manual DNS record with same name exists
 - Another ACME client managing the same domain
@@ -551,6 +554,7 @@ Charon displays instructions to remove the TXT record after certificate issuance
 **Symptom**: "Too many requests" or "Rate limit exceeded" errors.
 
 **Causes**:
+
 - Too many certificate requests in short period
 - DNS provider API rate limits
 - Let's Encrypt rate limits

docs/features/docker-integration.md

@@ -47,6 +47,7 @@ Docker auto-discovery eliminates manual IP address hunting and port memorization
 For Charon to discover containers, it needs Docker API access.
 
 **Docker Compose:**
+
 ```yaml
 services:
   charon:
@@ -56,6 +57,7 @@ services:
 ```
 
 **Docker Run:**
+
 ```bash
 docker run -v /var/run/docker.sock:/var/run/docker.sock:ro charon
 ```

docs/features/notifications.md

@@ -19,6 +19,7 @@ Notifications can be triggered by various events:
 | **Slack** | ✅ Yes | ✅ Webhooks | ✅ Native Formatting |
 | **Gotify** | ✅ Yes | ✅ HTTP API | ✅ Priority + Extras |
 | **Pushover** | ✅ Yes | ✅ HTTP API | ✅ Priority + Sound |
+| **Ntfy** | ✅ Yes | ✅ HTTP API | ✅ Priority + Tags |
 | **Custom Webhook** | ✅ Yes | ✅ HTTP API | ✅ Template-Controlled |
 | **Email** | ❌ No | ✅ SMTP | ✅ HTML Branded Templates |
 
@@ -260,6 +261,51 @@ Pushover delivers push notifications directly to your iOS, Android, or desktop d
 
 > **Note:** Emergency priority (`2`) is not supported and will be rejected with a clear error.
 
+### Ntfy
+
+Ntfy delivers push notifications to your phone or desktop using a simple HTTP-based publish/subscribe model. Works with the free hosted service at [ntfy.sh](https://ntfy.sh) or your own self-hosted instance.
+
+**Setup:**
+
+1. Pick a topic name (or use an existing one) on [ntfy.sh](https://ntfy.sh) or your self-hosted server
+2. In Charon, go to **Settings** → **Notifications** and click **"Add Provider"**
+3. Select **Ntfy** as the service type
+4. Enter your Topic URL (e.g., `https://ntfy.sh/charon-alerts` or `https://ntfy.example.com/charon-alerts`)
+5. (Optional) Add an access token if your topic requires authentication
+6. Configure notification triggers and save
+
+> **Security:** Your access token is stored securely and is never exposed in API responses.
+
+#### Basic Message
+
+```json
+{
+  "topic": "charon-alerts",
+  "title": "{{.Title}}",
+  "message": "{{.Message}}"
+}
+```
+
+#### Message with Priority and Tags
+
+```json
+{
+  "topic": "charon-alerts",
+  "title": "{{.Title}}",
+  "message": "{{.Message}}",
+  "priority": 4,
+  "tags": ["rotating_light"]
+}
+```
+
+**Ntfy priority levels:**
+
+- `1` - Min
+- `2` - Low
+- `3` - Default
+- `4` - High
+- `5` - Max (urgent)
+
 ## Planned Provider Expansion
 
 Additional providers (for example Telegram) are planned for later staged

docs/features/plugin-security.md

@@ -35,18 +35,21 @@ CHARON_PLUGIN_SIGNATURES='{"pluginname": "sha256:..."}'
 ### Examples
 
 **Permissive mode (default)**:
+
 ```bash
 # Unset — all plugins load without verification
 unset CHARON_PLUGIN_SIGNATURES
 ```
 
 **Strict block-all**:
+
 ```bash
 # Empty object — no external plugins will load
 export CHARON_PLUGIN_SIGNATURES='{}'
 ```
 
 **Allowlist specific plugins**:
+
 ```bash
 # Only powerdns and custom-provider plugins are allowed
 export CHARON_PLUGIN_SIGNATURES='{"powerdns": "sha256:a1b2c3d4...", "custom-provider": "sha256:e5f6g7h8..."}'
@@ -63,6 +66,7 @@ sha256sum myplugin.so | awk '{print "sha256:" $1}'
 ```
 
 **Example output**:
+
 ```
 sha256:a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6a7b8c9d0e1f2
 ```
@@ -96,6 +100,7 @@ services:
 ```
 
 This prevents runtime modification of plugin files, mitigating:
+
 - Time-of-check to time-of-use (TOCTOU) attacks
 - Malicious plugin replacement after signature verification
 
@@ -113,6 +118,7 @@ services:
 ```
 
 Or in Dockerfile:
+
 ```dockerfile
 FROM charon:latest
 USER charon
@@ -128,6 +134,7 @@ Plugin directories must **not** be world-writable. Charon enforces this at start
 | `0777` (world-writable) | ❌ Rejected — plugin loading disabled |
 
 **Set secure permissions**:
+
 ```bash
 chmod 755 /path/to/plugins
 chmod 644 /path/to/plugins/*.so  # Or 755 for executable
@@ -192,22 +199,26 @@ After updating plugins, always update your `CHARON_PLUGIN_SIGNATURES` with the n
 ### Checking if a Plugin Loaded
 
 **Check startup logs**:
+
 ```bash
 docker compose logs charon | grep -i plugin
 ```
 
 **Expected success output**:
+
 ```
 INFO Loaded DNS provider plugin type=powerdns name="PowerDNS" version="1.0.0"
 INFO Loaded 1 external DNS provider plugins (0 failed)
 ```
 
 **If using allowlist**:
+
 ```
 INFO Plugin signature allowlist enabled with 2 entries
 ```
 
 **Via API**:
+
 ```bash
 curl http://localhost:8080/api/admin/plugins \
   -H "Authorization: Bearer YOUR-TOKEN"
@@ -220,6 +231,7 @@ curl http://localhost:8080/api/admin/plugins \
 **Cause**: The plugin filename (without `.so`) is not in `CHARON_PLUGIN_SIGNATURES`.
 
 **Solution**: Add the plugin to your allowlist:
+
 ```bash
 # Get the signature
 sha256sum powerdns.so | awk '{print "sha256:" $1}'
@@ -233,6 +245,7 @@ export CHARON_PLUGIN_SIGNATURES='{"powerdns": "sha256:YOUR_HASH_HERE"}'
 **Cause**: The plugin file's SHA-256 hash doesn't match the allowlist.
 
 **Solution**:
+
 1. Verify you have the correct plugin file
 2. Re-compute the signature: `sha256sum plugin.so`
 3. Update `CHARON_PLUGIN_SIGNATURES` with the correct hash
@@ -242,6 +255,7 @@ export CHARON_PLUGIN_SIGNATURES='{"powerdns": "sha256:YOUR_HASH_HERE"}'
 **Cause**: The plugin directory is world-writable (mode `0777` or similar).
 
 **Solution**:
+
 ```bash
 chmod 755 /path/to/plugins
 chmod 644 /path/to/plugins/*.so
@@ -252,11 +266,13 @@ chmod 644 /path/to/plugins/*.so
 **Cause**: Malformed JSON in the environment variable.
 
 **Solution**: Validate your JSON:
+
 ```bash
 echo '{"powerdns": "sha256:abc123"}' | jq .
 ```
 
 Common issues:
+
 - Missing quotes around keys or values
 - Trailing commas
 - Single quotes instead of double quotes
@@ -266,6 +282,7 @@ Common issues:
 **Cause**: File permissions too restrictive or ownership mismatch.
 
 **Solution**:
+
 ```bash
 # Check current permissions
 ls -la /path/to/plugins/
@@ -278,27 +295,32 @@ chown charon:charon /path/to/plugins/*.so
 ### Debugging Checklist
 
 1. **Is the plugin directory configured?**
+
    ```bash
    echo $CHARON_PLUGINS_DIR
    ```
 
 2. **Does the plugin file exist?**
+
    ```bash
    ls -la $CHARON_PLUGINS_DIR/*.so
    ```
 
 3. **Are directory permissions secure?**
+
    ```bash
    stat -c "%a %n" $CHARON_PLUGINS_DIR
    # Should be 755 or stricter
    ```
 
 4. **Is the signature correct?**
+
    ```bash
    sha256sum $CHARON_PLUGINS_DIR/myplugin.so
    ```
 
 5. **Is the JSON valid?**
+
    ```bash
    echo "$CHARON_PLUGIN_SIGNATURES" | jq .
    ```

docs/features/proxy-headers.md

@@ -69,22 +69,26 @@ X-Forwarded-Host preserves the original domain:
 Your backend must trust proxy headers from Charon. Common configurations:
 
 **Node.js/Express:**
+
 ```javascript
 app.set('trust proxy', true);
 ```
 
 **Django:**
+
 ```python
 SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
 USE_X_FORWARDED_HOST = True
 ```
 
 **Rails:**
+
 ```ruby
 config.action_dispatch.trusted_proxies = [IPAddr.new('10.0.0.0/8')]
 ```
 
 **PHP/Laravel:**
+
 ```php
 // In TrustProxies middleware
 protected $proxies = '*';

docs/features/ssl-certificates.md

@@ -62,6 +62,21 @@ When you delete a proxy host, Charon automatically:
 
 This prevents certificate accumulation and keeps your system tidy.
 
+## Manual Certificate Deletion
+
+Over time, expired or unused certificates can pile up in the Certificates list. You can remove them manually:
+
+| Certificate Type | When You Can Delete It |
+|------------------|----------------------|
+| **Expired Let's Encrypt** | When it's not attached to any proxy host |
+| **Custom (uploaded)** | When it's not attached to any proxy host |
+| **Staging** | When it's not attached to any proxy host |
+| **Valid Let's Encrypt** | Managed automatically — no delete button shown |
+
+If a certificate is still attached to a proxy host, the delete button is disabled and a tooltip explains which host is using it. Remove the certificate from the proxy host first, then come back to delete it.
+
+A confirmation dialog appears before anything is removed. Charon creates a backup before deleting, so you have a safety net.
+
 ## Troubleshooting
 
 | Issue | Solution |

docs/getting-started.md

@@ -229,16 +229,19 @@ The emergency token is a security feature that allows bypassing all security mod
 Choose your platform:
 
 **Linux/macOS (recommended):**
+
 ```bash
 openssl rand -hex 32
 ```
 
 **Windows PowerShell:**
+
 ```powershell
 [Convert]::ToBase64String([System.Security.Cryptography.RandomNumberGenerator]::GetBytes(32))
 ```
 
 **Node.js (all platforms):**
+
 ```bash
 node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
 ```
@@ -252,11 +255,13 @@ CHARON_EMERGENCY_TOKEN=<paste_64_character_token_here>
 ```
 
 **Example:**
+
 ```bash
 CHARON_EMERGENCY_TOKEN=7b3b8a36a6fad839f1b3122131ed4b1f05453118a91b53346482415796e740e2
 ```
 
 **Verify:**
+
 ```bash
 # Token should be exactly 64 characters
 echo -n "$(grep CHARON_EMERGENCY_TOKEN .env | cut -d= -f2)" | wc -c
@@ -287,20 +292,23 @@ For continuous integration, store the token in GitHub Secrets:
 ### Security Best Practices
 
 ✅ **DO:**
+
 - Generate tokens using cryptographically secure methods
 - Store in `.env` (gitignored) or secrets management
 - Rotate quarterly or after security events
 - Use minimum 64 characters
 
 ❌ **DON'T:**
+
 - Commit tokens to repository (even in examples)
 - Share tokens via email or chat
 - Use weak or predictable values
 - Reuse tokens across environments
 
 ---
-2. **Settings table** for `security.crowdsec.enabled = "true"`
-3. **Starts CrowdSec** if either condition is true
+
+1. **Settings table** for `security.crowdsec.enabled = "true"`
+2. **Starts CrowdSec** if either condition is true
 
 **How it works:**
 
@@ -582,7 +590,7 @@ Click "Watch" → "Custom" → Select "Security advisories" on the [Charon repos
 
 **2. Notifications and Automatic Updates with Dockhand**
 
-  - Dockhand is a free service that monitors Docker images for updates and can send notifications or trigger auto-updates. https://github.com/Finsys/dockhand
+- Dockhand is a free service that monitors Docker images for updates and can send notifications or trigger auto-updates. <https://github.com/Finsys/dockhand>
 
 **Best Practices:**
 

docs/github-setup.md

@@ -68,6 +68,7 @@ E2E tests require an emergency token to be configured in GitHub Secrets. This to
 ### Why This Is Needed
 
 The emergency token is used by E2E tests to:
+
 - Disable security modules (ACL, WAF, CrowdSec) after testing them
 - Prevent cascading test failures due to leftover security state
 - Ensure tests can always access the API regardless of security configuration
@@ -77,16 +78,19 @@ The emergency token is used by E2E tests to:
 1. **Generate emergency token:**
 
    **Linux/macOS:**
+
    ```bash
    openssl rand -hex 32
    ```
 
    **Windows PowerShell:**
+
    ```powershell
    [Convert]::ToBase64String([System.Security.Cryptography.RandomNumberGenerator]::GetBytes(32))
    ```
 
    **Node.js (all platforms):**
+
    ```bash
    node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
    ```
@@ -141,11 +145,13 @@ If the secret is missing or invalid, the workflow will fail with a clear error m
 ### Security Best Practices
 
 ✅ **DO:**
+
 - Use cryptographically secure generation methods
 - Rotate quarterly or after security events
 - Store separately for local dev (`.env`) and CI/CD (GitHub Secrets)
 
 ❌ **DON'T:**
+
 - Share tokens via email or chat
 - Commit tokens to repository (even in example files)
 - Reuse tokens across different environments
@@ -154,11 +160,13 @@ If the secret is missing or invalid, the workflow will fail with a clear error m
 ### Troubleshooting
 
 **Error: "CHARON_EMERGENCY_TOKEN not set"**
+
 - Check secret name is exactly `CHARON_EMERGENCY_TOKEN` (case-sensitive)
 - Verify secret is repository-level, not environment-level
 - Re-run workflow after adding secret
 
 **Error: "Token too short"**
+
 - Hex method must generate exactly 64 characters
 - Verify you copied the entire token value
 - Regenerate if needed

docs/guides/crowdsec-setup.md

@@ -88,6 +88,7 @@ In CrowdSec terms:
 > **✅ Good News: Charon Handles This For You!**
 >
 > When you enable CrowdSec for the first time, Charon automatically:
+>
 > 1. Starts the CrowdSec engine
 > 2. Registers a bouncer and generates a valid API key
 > 3. Saves the key so it survives container restarts
@@ -317,11 +318,13 @@ Replace `YOUR_ENROLLMENT_KEY` with the key from your Console.
 **Solution:**
 
 1. Check if you're manually setting an API key:
+
    ```bash
    grep -i "crowdsec_api_key" docker-compose.yml
    ```
 
 2. If you find one, **remove it**:
+
    ```yaml
    # REMOVE this line:
    - CHARON_SECURITY_CROWDSEC_API_KEY=anything
@@ -330,6 +333,7 @@ Replace `YOUR_ENROLLMENT_KEY` with the key from your Console.
 3. Follow the [Manual Bouncer Registration](#manual-bouncer-registration) steps above
 
 4. Restart the container:
+
    ```bash
    docker restart charon
    ```
@@ -347,6 +351,7 @@ Replace `YOUR_ENROLLMENT_KEY` with the key from your Console.
 1. Wait 60 seconds after container start
 
 2. Check if CrowdSec is running:
+
    ```bash
    docker exec charon cscli lapi status
    ```
@@ -354,6 +359,7 @@ Replace `YOUR_ENROLLMENT_KEY` with the key from your Console.
 3. If you see "connection refused," try toggling CrowdSec OFF then ON in the GUI
 
 4. Check the logs:
+
    ```bash
    docker logs charon | grep -i crowdsec
    ```
@@ -431,6 +437,7 @@ If you already run CrowdSec separately (not inside Charon), you can connect to i
 **Steps:**
 
 1. Register a bouncer on your external CrowdSec:
+
    ```bash
    cscli bouncers add charon-bouncer
    ```
@@ -438,6 +445,7 @@ If you already run CrowdSec separately (not inside Charon), you can connect to i
 2. Save the API key that's generated (you won't see it again!)
 
 3. In your docker-compose.yml:
+
    ```yaml
    environment:
      - CHARON_SECURITY_CROWDSEC_API_URL=http://your-crowdsec-server:8080
@@ -445,6 +453,7 @@ If you already run CrowdSec separately (not inside Charon), you can connect to i
    ```
 
 4. Restart Charon:
+
    ```bash
    docker restart charon
    ```

docs/issues/certificate-delete-manual-test.md

@@ -0,0 +1,68 @@
+---
+title: "Manual Testing: Certificate Deletion UX Enhancement"
+labels:
+  - testing
+  - feature
+  - frontend
+priority: medium
+assignees: []
+---
+
+# Manual Testing: Certificate Deletion UX Enhancement
+
+## Description
+
+Manual test plan for expanded certificate deletion. Focuses on edge cases and race conditions that automated E2E tests cannot fully cover.
+
+## Pre-requisites
+
+- A running Charon instance with certificates in various states:
+  - At least one expired Let's Encrypt certificate **not** attached to a proxy host
+  - At least one custom (uploaded) certificate **not** attached to a proxy host
+  - At least one certificate **attached** to a proxy host (in use)
+  - At least one valid (non-expired) Let's Encrypt production certificate not in use
+- Access to the Charon Certificates page
+
+## Test Cases
+
+### Happy Path
+
+- [ ] **Delete expired LE cert not in use**: Click the delete button on an expired Let's Encrypt certificate that is not attached to any proxy host. Confirm in the dialog. Certificate disappears from the list and a success toast appears.
+- [ ] **Delete custom cert not in use**: Click the delete button on an uploaded custom certificate not attached to any host. Confirm. Certificate is removed with a success toast.
+- [ ] **Delete staging cert not in use**: Click the delete button on a staging certificate not attached to any host. Confirm. Certificate is removed with a success toast.
+
+### Delete Prevention
+
+- [ ] **In-use cert shows disabled button**: Find a certificate attached to a proxy host. Verify the delete button is visible but disabled.
+- [ ] **In-use cert tooltip**: Hover over the disabled delete button. A tooltip should explain that the certificate is in use and cannot be deleted.
+- [ ] **Valid LE cert hides delete button**: Find a valid (non-expired) Let's Encrypt production certificate not attached to any host. Verify no delete button is shown — Charon manages these automatically.
+
+### Confirmation Dialog
+
+- [ ] **Cancel does not delete**: Click the delete button on a deletable certificate. In the confirmation dialog, click Cancel. The certificate should remain in the list.
+- [ ] **Escape key closes dialog**: Open the confirmation dialog. Press Escape. The dialog closes and the certificate remains.
+- [ ] **Click overlay closes dialog**: Open the confirmation dialog. Click outside the dialog (on the overlay). The dialog closes and the certificate remains.
+- [ ] **Confirm deletes**: Open the confirmation dialog. Click the Delete/Confirm button. The certificate is removed and a success toast appears.
+
+### Keyboard Navigation
+
+- [ ] **Tab through dialog**: Open the confirmation dialog. Press Tab to move focus between the Cancel and Delete buttons. Focus order should be logical (Cancel → Delete or Delete → Cancel).
+- [ ] **Enter activates focused button**: Tab to the Cancel button and press Enter — dialog closes, certificate remains. Repeat with the Delete button — certificate is removed.
+- [ ] **Focus trap**: With the dialog open, Tab should cycle within the dialog and not escape to the page behind it.
+
+### Edge Cases & Race Conditions
+
+- [ ] **Rapid double-click on delete**: Quickly double-click the delete button. Only one confirmation dialog should appear. Only one delete request should be sent.
+- [ ] **Cert becomes in-use between dialog open and confirm**: Open the delete dialog for a certificate. In another tab, attach that certificate to a proxy host. Return and confirm deletion. The server should return a 409 error and the UI should show an appropriate error message — the certificate should remain.
+- [ ] **Delete when backup may fail (low disk space)**: If testable, simulate low disk space. Attempt a deletion. The server creates a backup before deleting — verify the error is surfaced to the user if the backup fails.
+- [ ] **Network error during delete**: Open the delete dialog and disconnect from the network (or throttle to offline in DevTools). Confirm deletion. An error message should appear and the certificate should remain.
+
+### Visual & UX Consistency
+
+- [ ] **Dialog styling**: The confirmation dialog should match the application theme (dark/light mode).
+- [ ] **Toast messages**: Success and error toasts should appear in the expected position and auto-dismiss.
+- [ ] **List updates without full reload**: After a successful deletion, the certificate list should update without requiring a page refresh.
+
+## Related
+
+- [Automatic HTTPS Certificates](../features/ssl-certificates.md)

docs/issues/ntfy-notification-provider-manual-testing.md

@@ -0,0 +1,98 @@
+---
+title: "Manual Testing: Ntfy Notification Provider"
+labels:
+  - testing
+  - feature
+  - frontend
+  - backend
+priority: medium
+milestone: "v0.2.0-beta.2"
+assignees: []
+---
+
+# Manual Testing: Ntfy Notification Provider
+
+## Description
+
+Manual testing plan for the Ntfy notification provider feature. Covers UI/UX
+validation, dispatch behavior, token security, and edge cases that E2E tests
+cannot fully cover.
+
+## Prerequisites
+
+- Ntfy instance accessible (cloud: ntfy.sh, or self-hosted)
+- Test topic created (e.g., `https://ntfy.sh/charon-test-XXXX`)
+- Ntfy mobile/desktop app installed for push verification
+- Optional: password-protected topic with access token for auth testing
+
+## Test Cases
+
+### UI/UX Validation
+
+- [ ] Select "Ntfy" from provider type dropdown — token field and "Topic URL" label appear
+- [ ] URL placeholder shows `https://ntfy.sh/my-topic`
+- [ ] Token label shows "Access Token (optional)"
+- [ ] Token field is a password field (dots, not cleartext)
+- [ ] JSON template section (minimal/detailed/custom) appears for Ntfy
+- [ ] Switching from Ntfy to Discord clears token field and hides it
+- [ ] Switching from Discord to Ntfy shows token field again
+- [ ] URL field is required — form rejects empty URL submission
+- [ ] Keyboard navigation: tab through all Ntfy form fields without focus traps
+
+### CRUD Operations
+
+- [ ] Create Ntfy provider with URL only (no token) — succeeds
+- [ ] Create Ntfy provider with URL + token — succeeds
+- [ ] Edit Ntfy provider: change URL — preserves token (shows "Leave blank to keep")
+- [ ] Edit Ntfy provider: clear and re-enter token — updates token
+- [ ] Delete Ntfy provider — removed from list
+- [ ] Create multiple Ntfy providers with different topics — all coexist
+
+### Dispatch Verification (Requires Real Ntfy Instance)
+
+- [ ] Send test notification to ntfy.sh cloud topic — push received on device
+- [ ] Send test notification to self-hosted ntfy instance — push received
+- [ ] Send test notification with minimal template — message body is correct
+- [ ] Send test notification with detailed template — title and body formatted correctly
+- [ ] Send test notification with custom JSON template — all fields arrive as specified
+- [ ] Token-protected topic with valid token — notification delivered
+- [ ] Token-protected topic with no token — notification rejected by ntfy (expected 401)
+- [ ] Token-protected topic with invalid token — notification rejected by ntfy (expected 401)
+
+### Token Security
+
+- [ ] After creating provider with token: GET provider response has `has_token: true` but no raw token
+- [ ] Browser DevTools Network tab: confirm token never appears in any API response body
+- [ ] Edit provider: token field is empty (not pre-filled with existing token)
+- [ ] Application logs: confirm no token values in backend logs during dispatch
+
+### Edge Cases
+
+- [ ] Invalid URL (not http/https) — form validation rejects
+- [ ] Self-hosted ntfy URL with non-standard port (e.g., `http://192.168.1.50:8080/alerts`) — accepted and dispatches
+- [ ] Very long topic name in URL — accepted
+- [ ] Unicode characters in message template — dispatches correctly
+- [ ] Feature flag disabled (`feature.notifications.service.ntfy.enabled = false`) — ntfy dispatch silently skipped
+- [ ] Network timeout to unreachable ntfy server — error handled gracefully, no crash
+
+### Accessibility
+
+- [ ] Screen reader: form field labels announced correctly for Ntfy fields
+- [ ] Screen reader: token help text associated via aria-describedby
+- [ ] High contrast mode: Ntfy form fields visible and readable
+- [ ] Voice access: "Click Topic URL" activates the correct field
+- [ ] Keyboard only: complete full CRUD workflow without mouse
+
+## Acceptance Criteria
+
+- [ ] All UI/UX tests pass
+- [ ] All CRUD operations work correctly
+- [ ] At least one real dispatch to ntfy.sh confirmed
+- [ ] Token never exposed in API responses or logs
+- [ ] No accessibility regressions
+
+## Related
+
+- Spec: `docs/plans/current_spec.md`
+- QA Report: `docs/reports/qa_report_ntfy_notifications.md`
+- E2E Tests: `tests/settings/ntfy-notification-provider.spec.ts`

docs/maintenance/README.md

@@ -9,6 +9,7 @@ This directory contains operational maintenance guides for keeping Charon runnin
 **When to use:** Docker build fails with GeoLite2-Country.mmdb checksum mismatch
 
 **Topics covered:**
+
 - Automated weekly checksum verification workflow
 - Manual checksum update procedures (5 minutes)
 - Verification script for checking upstream changes
@@ -16,6 +17,7 @@ This directory contains operational maintenance guides for keeping Charon runnin
 - Alternative sources if upstream mirrors are unavailable
 
 **Quick fix:**
+
 ```bash
 # Download and update checksum automatically
 NEW_CHECKSUM=$(curl -fsSL "https://github.com/P3TERX/GeoLite.mmdb/raw/download/GeoLite2-Country.mmdb" | sha256sum | cut -d' ' -f1)
@@ -34,6 +36,7 @@ Found a maintenance issue not covered here? Please:
 3. **Update this index** with a link to your guide
 
 **Format:**
+
 ```markdown
 ### [Guide Title](filename.md)
 

docs/maintenance/geolite2-checksum-update.md

@@ -15,6 +15,7 @@ Charon uses the [MaxMind GeoLite2-Country database](https://dev.maxmind.com/geoi
 Update the checksum when:
 
 1. **Docker build fails** with the following error:
+
    ```
    sha256sum: /app/data/geoip/GeoLite2-Country.mmdb: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
@@ -29,6 +30,7 @@ Update the checksum when:
 ## Automated Workflow (Recommended)
 
 Charon includes a GitHub Actions workflow that automatically:
+
 - Checks for upstream GeoLite2 database changes weekly
 - Calculates the new checksum
 - Creates a pull request with the update
@@ -39,6 +41,7 @@ Charon includes a GitHub Actions workflow that automatically:
 **Schedule:** Mondays at 2 AM UTC (weekly)
 
 **Manual Trigger:**
+
 ```bash
 gh workflow run update-geolite2.yml
 ```
@@ -75,16 +78,19 @@ sha256sum /tmp/geolite2-test.mmdb
 **File:** [`Dockerfile`](../../Dockerfile) (line ~352)
 
 **Find this line:**
+
 ```dockerfile
 ARG GEOLITE2_COUNTRY_SHA256=<old-checksum>
 ```
 
 **Replace with the new checksum:**
+
 ```dockerfile
 ARG GEOLITE2_COUNTRY_SHA256=436135ee98a521da715a6d483951f3dbbd62557637f2d50d1987fc048874bd5d
 ```
 
 **Using sed (automated):**
+
 ```bash
 NEW_CHECKSUM=$(curl -fsSL "https://github.com/P3TERX/GeoLite.mmdb/raw/download/GeoLite2-Country.mmdb" | sha256sum | cut -d' ' -f1)
 
@@ -119,6 +125,7 @@ docker run --rm charon:test-checksum /app/charon --version
 ```
 
 **Expected output:**
+
 ```
 ✅ GeoLite2-Country.mmdb: OK
 ✅ Successfully tagged charon:test-checksum
@@ -171,11 +178,13 @@ fi
 ```
 
 **Make executable:**
+
 ```bash
 chmod +x scripts/verify-geolite2-checksum.sh
 ```
 
 **Run verification:**
+
 ```bash
 ./scripts/verify-geolite2-checksum.sh
 ```
@@ -187,22 +196,26 @@ chmod +x scripts/verify-geolite2-checksum.sh
 ### Issue: Build Still Fails After Update
 
 **Symptoms:**
+
 - Checksum verification fails
 - "FAILED" error persists
 
 **Solutions:**
 
 1. **Clear Docker build cache:**
+
    ```bash
    docker builder prune -af
    ```
 
 2. **Verify the checksum was committed:**
+
    ```bash
    git show HEAD:Dockerfile | grep "GEOLITE2_COUNTRY_SHA256"
    ```
 
 3. **Re-download and verify upstream file:**
+
    ```bash
    curl -fsSL "https://github.com/P3TERX/GeoLite.mmdb/raw/download/GeoLite2-Country.mmdb" -o /tmp/test.mmdb
    sha256sum /tmp/test.mmdb
@@ -212,28 +225,31 @@ chmod +x scripts/verify-geolite2-checksum.sh
 ### Issue: Upstream File Unavailable (404)
 
 **Symptoms:**
+
 - `curl` returns 404 Not Found
 - Automated workflow fails with `download_failed` error
 
 **Investigation Steps:**
 
 1. **Check upstream repository:**
-   - Visit: https://github.com/P3TERX/GeoLite.mmdb
+   - Visit: <https://github.com/P3TERX/GeoLite.mmdb>
    - Verify the file still exists at the raw URL
    - Check for repository status or announcements
 
 2. **Check MaxMind status:**
-   - Visit: https://status.maxmind.com/
+   - Visit: <https://status.maxmind.com/>
    - Check for service outages or maintenance
 
 **Temporary Solutions:**
 
 1. **Use cached Docker layer** (if available):
+
    ```bash
    docker build --cache-from ghcr.io/wikid82/charon:latest -t charon:latest .
    ```
 
 2. **Use local copy** (temporary):
+
    ```bash
    # Download from a working container
    docker run --rm ghcr.io/wikid82/charon:latest cat /app/data/geoip/GeoLite2-Country.mmdb > /tmp/GeoLite2-Country.mmdb
@@ -249,12 +265,14 @@ chmod +x scripts/verify-geolite2-checksum.sh
 ### Issue: Checksum Mismatch on Re-download
 
 **Symptoms:**
+
 - Checksum calculated locally differs from what's in the Dockerfile
 - Checksum changes between downloads
 
 **Investigation Steps:**
 
 1. **Verify file integrity:**
+
    ```bash
    # Download multiple times and compare
    for i in {1..3}; do
@@ -267,12 +285,14 @@ chmod +x scripts/verify-geolite2-checksum.sh
    - Try from different network locations
 
 3. **Verify no MITM proxy:**
+
    ```bash
    # Download via HTTPS and verify certificate
    curl -v -fsSL "https://github.com/P3TERX/GeoLite.mmdb/raw/download/GeoLite2-Country.mmdb" -o /tmp/test.mmdb 2>&1 | grep "CN="
    ```
 
 **If confirmed as supply chain attack:**
+
 - **STOP** and do not proceed
 - Report to security team
 - See [Security Incident Response](../security-incident-response.md)
@@ -280,6 +300,7 @@ chmod +x scripts/verify-geolite2-checksum.sh
 ### Issue: Multi-Platform Build Fails (arm64)
 
 **Symptoms:**
+
 - `linux/amd64` build succeeds
 - `linux/arm64` build fails with checksum error
 
@@ -290,12 +311,14 @@ chmod +x scripts/verify-geolite2-checksum.sh
    - Should be identical across all platforms
 
 2. **Check buildx platform emulation:**
+
    ```bash
    docker buildx ls
    docker buildx inspect
    ```
 
 3. **Test arm64 build explicitly:**
+
    ```bash
    docker buildx build --platform linux/arm64 --load -t test-arm64 .
    ```
@@ -308,8 +331,8 @@ chmod +x scripts/verify-geolite2-checksum.sh
 - **Implementation Plan:** [`docs/plans/current_spec.md`](../plans/current_spec.md)
 - **QA Report:** [`docs/reports/qa_report.md`](../reports/qa_report.md)
 - **Dockerfile:** [`Dockerfile`](../../Dockerfile) (line ~352)
-- **MaxMind GeoLite2:** https://dev.maxmind.com/geoip/geolite2-free-geolocation-data
-- **P3TERX Mirror:** https://github.com/P3TERX/GeoLite.mmdb
+- **MaxMind GeoLite2:** <https://dev.maxmind.com/geoip/geolite2-free-geolocation-data>
+- **P3TERX Mirror:** <https://github.com/P3TERX/GeoLite.mmdb>
 
 ---
 
@@ -321,9 +344,10 @@ chmod +x scripts/verify-geolite2-checksum.sh
 
 **Solution:** Updated one line in `Dockerfile` (line 352) with the correct checksum and implemented an automated workflow to prevent future occurrences.
 
-**Build Failure URL:** https://github.com/Wikid82/Charon/actions/runs/21584236523/job/62188372617
+**Build Failure URL:** <https://github.com/Wikid82/Charon/actions/runs/21584236523/job/62188372617>
 
 **Related PRs:**
+
 - Fix implementation: (link to PR)
 - Automated workflow addition: (link to PR)
 

docs/patches/e2e_workflow_timeout_fix.patch.md

@@ -6,8 +6,9 @@ index efbcccda..64fcc121 100644
      if: |
        ((inputs.browser || 'all') == 'chromium' || (inputs.browser || 'all') == 'all') &&
        ((inputs.test_category || 'all') == 'security' || (inputs.test_category || 'all') == 'all')
--    timeout-minutes: 40
-+    timeout-minutes: 60
+
+- timeout-minutes: 40
+- timeout-minutes: 60
      env:
        CHARON_EMERGENCY_TOKEN: ${{ secrets.CHARON_EMERGENCY_TOKEN }}
        CHARON_EMERGENCY_SERVER_ENABLED: "true"
@@ -15,42 +16,45 @@ index efbcccda..64fcc121 100644
 
            npx playwright test \
              --project=chromium \
-+            --output=playwright-output/security-chromium \
+-            --output=playwright-output/security-chromium \
              tests/security-enforcement/ \
              tests/security/ \
              tests/integration/multi-feature-workflows.spec.ts || STATUS=$?
+
 @@ -370,6 +371,25 @@ jobs:
            path: test-results/**/*.zip
            retention-days: 7
 
-+      - name: Collect diagnostics
-+        if: always()
-+        run: |
-+          mkdir -p diagnostics
-+          uptime > diagnostics/uptime.txt
-+          free -m > diagnostics/free-m.txt
-+          df -h > diagnostics/df-h.txt
-+          ps aux > diagnostics/ps-aux.txt
-+          docker ps -a > diagnostics/docker-ps.txt || true
-+          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
-+
-+      - name: Upload diagnostics
-+        if: always()
-+        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
-+        with:
-+          name: e2e-diagnostics-chromium-security
-+          path: diagnostics/
-+          retention-days: 7
-+
+-      - name: Collect diagnostics
+-        if: always()
+-        run: |
+-          mkdir -p diagnostics
+-          uptime > diagnostics/uptime.txt
+-          free -m > diagnostics/free-m.txt
+-          df -h > diagnostics/df-h.txt
+-          ps aux > diagnostics/ps-aux.txt
+-          docker ps -a > diagnostics/docker-ps.txt || true
+-          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
+-
+-      - name: Upload diagnostics
+-        if: always()
+-        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
+-        with:
+-          name: e2e-diagnostics-chromium-security
+-          path: diagnostics/
+-          retention-days: 7
+-
        - name: Collect Docker logs on failure
          if: failure()
          run: |
+
 @@ -394,7 +414,7 @@ jobs:
      if: |
        ((inputs.browser || 'all') == 'firefox' || (inputs.browser || 'all') == 'all') &&
        ((inputs.test_category || 'all') == 'security' || (inputs.test_category || 'all') == 'all')
--    timeout-minutes: 40
-+    timeout-minutes: 60
+
+- timeout-minutes: 40
+- timeout-minutes: 60
      env:
        CHARON_EMERGENCY_TOKEN: ${{ secrets.CHARON_EMERGENCY_TOKEN }}
        CHARON_EMERGENCY_SERVER_ENABLED: "true"
@@ -58,42 +62,45 @@ index efbcccda..64fcc121 100644
 
            npx playwright test \
              --project=firefox \
-+            --output=playwright-output/security-firefox \
+-            --output=playwright-output/security-firefox \
              tests/security-enforcement/ \
              tests/security/ \
              tests/integration/multi-feature-workflows.spec.ts || STATUS=$?
+
 @@ -559,6 +580,25 @@ jobs:
            path: test-results/**/*.zip
            retention-days: 7
 
-+      - name: Collect diagnostics
-+        if: always()
-+        run: |
-+          mkdir -p diagnostics
-+          uptime > diagnostics/uptime.txt
-+          free -m > diagnostics/free-m.txt
-+          df -h > diagnostics/df-h.txt
-+          ps aux > diagnostics/ps-aux.txt
-+          docker ps -a > diagnostics/docker-ps.txt || true
-+          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
-+
-+      - name: Upload diagnostics
-+        if: always()
-+        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
-+        with:
-+          name: e2e-diagnostics-firefox-security
-+          path: diagnostics/
-+          retention-days: 7
-+
+-      - name: Collect diagnostics
+-        if: always()
+-        run: |
+-          mkdir -p diagnostics
+-          uptime > diagnostics/uptime.txt
+-          free -m > diagnostics/free-m.txt
+-          df -h > diagnostics/df-h.txt
+-          ps aux > diagnostics/ps-aux.txt
+-          docker ps -a > diagnostics/docker-ps.txt || true
+-          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
+-
+-      - name: Upload diagnostics
+-        if: always()
+-        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
+-        with:
+-          name: e2e-diagnostics-firefox-security
+-          path: diagnostics/
+-          retention-days: 7
+-
        - name: Collect Docker logs on failure
          if: failure()
          run: |
+
 @@ -583,7 +623,7 @@ jobs:
      if: |
        ((inputs.browser || 'all') == 'webkit' || (inputs.browser || 'all') == 'all') &&
        ((inputs.test_category || 'all') == 'security' || (inputs.test_category || 'all') == 'all')
--    timeout-minutes: 40
-+    timeout-minutes: 60
+
+- timeout-minutes: 40
+- timeout-minutes: 60
      env:
        CHARON_EMERGENCY_TOKEN: ${{ secrets.CHARON_EMERGENCY_TOKEN }}
        CHARON_EMERGENCY_SERVER_ENABLED: "true"
@@ -101,42 +108,45 @@ index efbcccda..64fcc121 100644
 
            npx playwright test \
              --project=webkit \
-+            --output=playwright-output/security-webkit \
+-            --output=playwright-output/security-webkit \
              tests/security-enforcement/ \
              tests/security/ \
              tests/integration/multi-feature-workflows.spec.ts || STATUS=$?
+
 @@ -748,6 +789,25 @@ jobs:
            path: test-results/**/*.zip
            retention-days: 7
 
-+      - name: Collect diagnostics
-+        if: always()
-+        run: |
-+          mkdir -p diagnostics
-+          uptime > diagnostics/uptime.txt
-+          free -m > diagnostics/free-m.txt
-+          df -h > diagnostics/df-h.txt
-+          ps aux > diagnostics/ps-aux.txt
-+          docker ps -a > diagnostics/docker-ps.txt || true
-+          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
-+
-+      - name: Upload diagnostics
-+        if: always()
-+        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
-+        with:
-+          name: e2e-diagnostics-webkit-security
-+          path: diagnostics/
-+          retention-days: 7
-+
+-      - name: Collect diagnostics
+-        if: always()
+-        run: |
+-          mkdir -p diagnostics
+-          uptime > diagnostics/uptime.txt
+-          free -m > diagnostics/free-m.txt
+-          df -h > diagnostics/df-h.txt
+-          ps aux > diagnostics/ps-aux.txt
+-          docker ps -a > diagnostics/docker-ps.txt || true
+-          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
+-
+-      - name: Upload diagnostics
+-        if: always()
+-        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
+-        with:
+-          name: e2e-diagnostics-webkit-security
+-          path: diagnostics/
+-          retention-days: 7
+-
        - name: Collect Docker logs on failure
          if: failure()
          run: |
+
 @@ -779,7 +839,7 @@ jobs:
      if: |
        ((inputs.browser || 'all') == 'chromium' || (inputs.browser || 'all') == 'all') &&
        ((inputs.test_category || 'all') == 'non-security' || (inputs.test_category || 'all') == 'all')
--    timeout-minutes: 30
-+    timeout-minutes: 60
+
+- timeout-minutes: 30
+- timeout-minutes: 60
      env:
        CHARON_EMERGENCY_TOKEN: ${{ secrets.CHARON_EMERGENCY_TOKEN }}
        CHARON_EMERGENCY_SERVER_ENABLED: "true"
@@ -144,57 +154,61 @@ index efbcccda..64fcc121 100644
            npx playwright test \
              --project=chromium \
              --shard=${{ matrix.shard }}/${{ matrix.total-shards }} \
-+            --output=playwright-output/chromium-shard-${{ matrix.shard }} \
+-            --output=playwright-output/chromium-shard-${{ matrix.shard }} \
              tests/core \
              tests/dns-provider-crud.spec.ts \
              tests/dns-provider-types.spec.ts \
+
 @@ -915,6 +976,14 @@ jobs:
            path: playwright-report/
            retention-days: 14
 
-+      - name: Upload Playwright output (Chromium shard ${{ matrix.shard }})
-+        if: always()
-+        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
-+        with:
-+          name: playwright-output-chromium-shard-${{ matrix.shard }}
-+          path: playwright-output/chromium-shard-${{ matrix.shard }}/
-+          retention-days: 7
-+
+-      - name: Upload Playwright output (Chromium shard ${{ matrix.shard }})
+-        if: always()
+-        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
+-        with:
+-          name: playwright-output-chromium-shard-${{ matrix.shard }}
+-          path: playwright-output/chromium-shard-${{ matrix.shard }}/
+-          retention-days: 7
+-
        - name: Upload Chromium coverage (if enabled)
          if: always() && (inputs.playwright_coverage == 'true' || vars.PLAYWRIGHT_COVERAGE == '1')
          uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
+
 @@ -931,6 +1000,25 @@ jobs:
            path: test-results/**/*.zip
            retention-days: 7
 
-+      - name: Collect diagnostics
-+        if: always()
-+        run: |
-+          mkdir -p diagnostics
-+          uptime > diagnostics/uptime.txt
-+          free -m > diagnostics/free-m.txt
-+          df -h > diagnostics/df-h.txt
-+          ps aux > diagnostics/ps-aux.txt
-+          docker ps -a > diagnostics/docker-ps.txt || true
-+          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
-+
-+      - name: Upload diagnostics
-+        if: always()
-+        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
-+        with:
-+          name: e2e-diagnostics-chromium-shard-${{ matrix.shard }}
-+          path: diagnostics/
-+          retention-days: 7
-+
+-      - name: Collect diagnostics
+-        if: always()
+-        run: |
+-          mkdir -p diagnostics
+-          uptime > diagnostics/uptime.txt
+-          free -m > diagnostics/free-m.txt
+-          df -h > diagnostics/df-h.txt
+-          ps aux > diagnostics/ps-aux.txt
+-          docker ps -a > diagnostics/docker-ps.txt || true
+-          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
+-
+-      - name: Upload diagnostics
+-        if: always()
+-        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
+-        with:
+-          name: e2e-diagnostics-chromium-shard-${{ matrix.shard }}
+-          path: diagnostics/
+-          retention-days: 7
+-
        - name: Collect Docker logs on failure
          if: failure()
          run: |
+
 @@ -955,7 +1043,7 @@ jobs:
      if: |
        ((inputs.browser || 'all') == 'firefox' || (inputs.browser || 'all') == 'all') &&
        ((inputs.test_category || 'all') == 'non-security' || (inputs.test_category || 'all') == 'all')
--    timeout-minutes: 30
-+    timeout-minutes: 60
+
+- timeout-minutes: 30
+- timeout-minutes: 60
      env:
        CHARON_EMERGENCY_TOKEN: ${{ secrets.CHARON_EMERGENCY_TOKEN }}
        CHARON_EMERGENCY_SERVER_ENABLED: "true"
@@ -202,57 +216,61 @@ index efbcccda..64fcc121 100644
            npx playwright test \
              --project=firefox \
              --shard=${{ matrix.shard }}/${{ matrix.total-shards }} \
-+            --output=playwright-output/firefox-shard-${{ matrix.shard }} \
+-            --output=playwright-output/firefox-shard-${{ matrix.shard }} \
              tests/core \
              tests/dns-provider-crud.spec.ts \
              tests/dns-provider-types.spec.ts \
+
 @@ -1099,6 +1188,14 @@ jobs:
            path: playwright-report/
            retention-days: 14
 
-+      - name: Upload Playwright output (Firefox shard ${{ matrix.shard }})
-+        if: always()
-+        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
-+        with:
-+          name: playwright-output-firefox-shard-${{ matrix.shard }}
-+          path: playwright-output/firefox-shard-${{ matrix.shard }}/
-+          retention-days: 7
-+
+-      - name: Upload Playwright output (Firefox shard ${{ matrix.shard }})
+-        if: always()
+-        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
+-        with:
+-          name: playwright-output-firefox-shard-${{ matrix.shard }}
+-          path: playwright-output/firefox-shard-${{ matrix.shard }}/
+-          retention-days: 7
+-
        - name: Upload Firefox coverage (if enabled)
          if: always() && (inputs.playwright_coverage == 'true' || vars.PLAYWRIGHT_COVERAGE == '1')
          uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
+
 @@ -1115,6 +1212,25 @@ jobs:
            path: test-results/**/*.zip
            retention-days: 7
 
-+      - name: Collect diagnostics
-+        if: always()
-+        run: |
-+          mkdir -p diagnostics
-+          uptime > diagnostics/uptime.txt
-+          free -m > diagnostics/free-m.txt
-+          df -h > diagnostics/df-h.txt
-+          ps aux > diagnostics/ps-aux.txt
-+          docker ps -a > diagnostics/docker-ps.txt || true
-+          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
-+
-+      - name: Upload diagnostics
-+        if: always()
-+        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
-+        with:
-+          name: e2e-diagnostics-firefox-shard-${{ matrix.shard }}
-+          path: diagnostics/
-+          retention-days: 7
-+
+-      - name: Collect diagnostics
+-        if: always()
+-        run: |
+-          mkdir -p diagnostics
+-          uptime > diagnostics/uptime.txt
+-          free -m > diagnostics/free-m.txt
+-          df -h > diagnostics/df-h.txt
+-          ps aux > diagnostics/ps-aux.txt
+-          docker ps -a > diagnostics/docker-ps.txt || true
+-          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
+-
+-      - name: Upload diagnostics
+-        if: always()
+-        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6.0.0
+-        with:
+-          name: e2e-diagnostics-firefox-shard-${{ matrix.shard }}
+-          path: diagnostics/
+-          retention-days: 7
+-
        - name: Collect Docker logs on failure
          if: failure()
          run: |
+
 @@ -1139,7 +1255,7 @@ jobs:
      if: |
        ((inputs.browser || 'all') == 'webkit' || (inputs.browser || 'all') == 'all') &&
        ((inputs.test_category || 'all') == 'non-security' || (inputs.test_category || 'all') == 'all')
--    timeout-minutes: 30
-+    timeout-minutes: 60
+
+- timeout-minutes: 30
+- timeout-minutes: 60
      env:
        CHARON_EMERGENCY_TOKEN: ${{ secrets.CHARON_EMERGENCY_TOKEN }}
        CHARON_EMERGENCY_SERVER_ENABLED: "true"
@@ -260,48 +278,50 @@ index efbcccda..64fcc121 100644
            npx playwright test \
              --project=webkit \
              --shard=${{ matrix.shard }}/${{ matrix.total-shards }} \
-+            --output=playwright-output/webkit-shard-${{ matrix.shard }} \
+-            --output=playwright-output/webkit-shard-${{ matrix.shard }} \
              tests/core \
              tests/dns-provider-crud.spec.ts \
              tests/dns-provider-types.spec.ts \
+
 @@ -1283,6 +1400,14 @@ jobs:
            path: playwright-report/
            retention-days: 14
 
-+      - name: Upload Playwright output (WebKit shard ${{ matrix.shard }})
-+        if: always()
-+        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6
-+        with:
-+          name: playwright-output-webkit-shard-${{ matrix.shard }}
-+          path: playwright-output/webkit-shard-${{ matrix.shard }}/
-+          retention-days: 7
-+
+-      - name: Upload Playwright output (WebKit shard ${{ matrix.shard }})
+-        if: always()
+-        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6
+-        with:
+-          name: playwright-output-webkit-shard-${{ matrix.shard }}
+-          path: playwright-output/webkit-shard-${{ matrix.shard }}/
+-          retention-days: 7
+-
        - name: Upload WebKit coverage (if enabled)
          if: always() && (inputs.playwright_coverage == 'true' || vars.PLAYWRIGHT_COVERAGE == '1')
          uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6
+
 @@ -1299,6 +1424,25 @@ jobs:
            path: test-results/**/*.zip
            retention-days: 7
 
-+      - name: Collect diagnostics
-+        if: always()
-+        run: |
-+          mkdir -p diagnostics
-+          uptime > diagnostics/uptime.txt
-+          free -m > diagnostics/free-m.txt
-+          df -h > diagnostics/df-h.txt
-+          ps aux > diagnostics/ps-aux.txt
-+          docker ps -a > diagnostics/docker-ps.txt || true
-+          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
-+
-+      - name: Upload diagnostics
-+        if: always()
-+        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6
-+        with:
-+          name: e2e-diagnostics-webkit-shard-${{ matrix.shard }}
-+          path: diagnostics/
-+          retention-days: 7
-+
+-      - name: Collect diagnostics
+-        if: always()
+-        run: |
+-          mkdir -p diagnostics
+-          uptime > diagnostics/uptime.txt
+-          free -m > diagnostics/free-m.txt
+-          df -h > diagnostics/df-h.txt
+-          ps aux > diagnostics/ps-aux.txt
+-          docker ps -a > diagnostics/docker-ps.txt || true
+-          docker logs --tail 500 charon-e2e > diagnostics/docker-charon-e2e.log 2>&1 || true
+-
+-      - name: Upload diagnostics
+-        if: always()
+-        uses: actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f # v6
+-        with:
+-          name: e2e-diagnostics-webkit-shard-${{ matrix.shard }}
+-          path: diagnostics/
+-          retention-days: 7
+-
        - name: Collect Docker logs on failure
          if: failure()
          run: |

docs/performance/feature-flags-endpoint.md

@@ -31,6 +31,7 @@ for _, s := range settings {
 ```
 
 **Key Improvements:**
+
 - **Single Query:** `WHERE key IN (?, ?, ?)` fetches all flags in one database round-trip
 - **O(1) Lookups:** Map-based access eliminates linear search overhead
 - **Error Handling:** Explicit error logging and HTTP 500 response on failure
@@ -56,6 +57,7 @@ if err := h.DB.Transaction(func(tx *gorm.DB) error {
 ```
 
 **Key Improvements:**
+
 - **Atomic Updates:** All flag changes commit or rollback together
 - **Error Recovery:** Transaction rollback prevents partial state
 - **Improved Logging:** Explicit error messages for debugging
@@ -65,10 +67,12 @@ if err := h.DB.Transaction(func(tx *gorm.DB) error {
 ### Before Optimization (Baseline - N+1 Pattern)
 
 **Architecture:**
+
 - GetFlags(): 3 sequential `WHERE key = ?` queries (one per flag)
 - UpdateFlags(): Multiple separate transactions
 
 **Measured Latency (Expected):**
+
 - **GET P50:** 300ms (CI environment)
 - **GET P95:** 500ms
 - **GET P99:** 600ms
@@ -77,20 +81,24 @@ if err := h.DB.Transaction(func(tx *gorm.DB) error {
 - **PUT P99:** 600ms
 
 **Query Count:**
+
 - GET: 3 queries (N+1 pattern, N=3 flags)
 - PUT: 1-3 queries depending on flag count
 
 **CI Impact:**
+
 - Test flakiness: ~30% failure rate due to timeouts
 - E2E test pass rate: ~70%
 
 ### After Optimization (Current - Batch Query + Transaction)
 
 **Architecture:**
+
 - GetFlags(): 1 batch query `WHERE key IN (?, ?, ?)`
 - UpdateFlags(): 1 transaction wrapping all updates
 
 **Measured Latency (Target):**
+
 - **GET P50:** 100ms (3x faster)
 - **GET P95:** 150ms (3.3x faster)
 - **GET P99:** 200ms (3x faster)
@@ -99,10 +107,12 @@ if err := h.DB.Transaction(func(tx *gorm.DB) error {
 - **PUT P99:** 200ms (3x faster)
 
 **Query Count:**
+
 - GET: 1 batch query (N+1 eliminated)
 - PUT: 1 transaction (atomic)
 
 **CI Impact (Expected):**
+
 - Test flakiness: 0% (with retry logic + polling)
 - E2E test pass rate: 100%
 
@@ -125,11 +135,13 @@ if err := h.DB.Transaction(func(tx *gorm.DB) error {
 **Status:** Complete
 
 **Changes:**
+
 - Added `defer` timing to GetFlags() and UpdateFlags()
 - Log format: `[METRICS] GET/PUT /feature-flags: {duration}ms`
 - CI pipeline captures P50/P95/P99 metrics
 
 **Files Modified:**
+
 - `backend/internal/api/handlers/feature_flags_handler.go`
 
 ### Phase 1: Backend Optimization - N+1 Query Fix
@@ -139,16 +151,19 @@ if err := h.DB.Transaction(func(tx *gorm.DB) error {
 **Priority:** P0 - Critical CI Blocker
 
 **Changes:**
+
 - **GetFlags():** Replaced N+1 loop with batch query `WHERE key IN (?)`
 - **UpdateFlags():** Wrapped updates in single transaction
 - **Tests:** Added batch query and transaction rollback tests
 - **Benchmarks:** Added BenchmarkGetFlags and BenchmarkUpdateFlags
 
 **Files Modified:**
+
 - `backend/internal/api/handlers/feature_flags_handler.go`
 - `backend/internal/api/handlers/feature_flags_handler_test.go`
 
 **Expected Impact:**
+
 - 3-6x latency reduction (600ms → 200ms P99)
 - Elimination of N+1 query anti-pattern
 - Atomic updates with rollback on error
@@ -159,32 +174,38 @@ if err := h.DB.Transaction(func(tx *gorm.DB) error {
 ### Test Helpers Used
 
 **Polling Helper:** `waitForFeatureFlagPropagation()`
+
 - Polls `/api/v1/feature-flags` until expected state confirmed
 - Default interval: 500ms
 - Default timeout: 30s (150x safety margin over 200ms P99)
 
 **Retry Helper:** `retryAction()`
+
 - 3 max attempts with exponential backoff (2s, 4s, 8s)
 - Handles transient network/DB failures
 
 ### Timeout Strategy
 
 **Helper Defaults:**
+
 - `clickAndWaitForResponse()`: 30s timeout
 - `waitForAPIResponse()`: 30s timeout
 - No explicit timeouts in test files (rely on helper defaults)
 
 **Typical Poll Count:**
+
 - Local: 1-2 polls (50-200ms response + 500ms interval)
 - CI: 1-3 polls (50-200ms response + 500ms interval)
 
 ### Test Files
 
 **E2E Tests:**
+
 - `tests/settings/system-settings.spec.ts` - Feature toggle tests
 - `tests/utils/wait-helpers.ts` - Polling and retry helpers
 
 **Backend Tests:**
+
 - `backend/internal/api/handlers/feature_flags_handler_test.go`
 - `backend/internal/api/handlers/feature_flags_handler_coverage_test.go`
 
@@ -205,11 +226,13 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 ### Benchmark Analysis
 
 **GetFlags Benchmark:**
+
 - Measures single batch query performance
 - Tests with 3 flags in database
 - Includes JSON serialization overhead
 
 **UpdateFlags Benchmark:**
+
 - Measures transaction wrapping performance
 - Tests atomic update of 3 flags
 - Includes JSON deserialization and validation
@@ -219,14 +242,17 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 ### Why Batch Query Over Individual Queries?
 
 **Problem:** N+1 pattern causes linear latency scaling
+
 - 3 flags = 3 queries × 200ms = 600ms total
 - 10 flags = 10 queries × 200ms = 2000ms total
 
 **Solution:** Single batch query with IN clause
+
 - N flags = 1 query × 200ms = 200ms total
 - Constant time regardless of flag count
 
 **Trade-offs:**
+
 - ✅ 3-6x latency reduction
 - ✅ Scales to more flags without performance degradation
 - ⚠️ Slightly more complex code (map-based lookup)
@@ -234,14 +260,17 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 ### Why Transaction Wrapping?
 
 **Problem:** Multiple separate writes risk partial state
+
 - Flag 1 succeeds, Flag 2 fails → inconsistent state
 - No rollback mechanism for failed updates
 
 **Solution:** Single transaction for all updates
+
 - All succeed together or all rollback
 - ACID guarantees for multi-flag updates
 
 **Trade-offs:**
+
 - ✅ Atomic updates with rollback on error
 - ✅ Prevents partial state corruption
 - ⚠️ Slightly longer locks (mitigated by fast SQLite)
@@ -253,11 +282,13 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 **Status:** Not implemented (not needed after Phase 1 optimization)
 
 **Rationale:**
+
 - Current latency (50-200ms) is acceptable for feature flags
 - Feature flags change infrequently (not a hot path)
 - Adding cache increases complexity without significant benefit
 
 **If Needed:**
+
 - Use Redis or in-memory cache with TTL=60s
 - Invalidate on PUT operations
 - Expected improvement: 50-200ms → 10-50ms
@@ -267,11 +298,13 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 **Status:** SQLite default indexes sufficient
 
 **Rationale:**
+
 - `settings.key` column used in WHERE clauses
 - SQLite automatically indexes primary key
 - Query plan analysis shows index usage
 
 **If Needed:**
+
 - Add explicit index: `CREATE INDEX idx_settings_key ON settings(key)`
 - Expected improvement: Minimal (already fast)
 
@@ -280,11 +313,13 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 **Status:** GORM default pooling sufficient
 
 **Rationale:**
+
 - GORM uses `database/sql` pool by default
 - Current concurrency limits adequate
 - No connection exhaustion observed
 
 **If Needed:**
+
 - Tune `SetMaxOpenConns()` and `SetMaxIdleConns()`
 - Expected improvement: 10-20% under high load
 
@@ -293,12 +328,14 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 ### Metrics to Track
 
 **Backend Metrics:**
+
 - P50/P95/P99 latency for GET and PUT operations
 - Query count per request (should remain 1 for GET)
 - Transaction count per PUT (should remain 1)
 - Error rate (target: <0.1%)
 
 **E2E Metrics:**
+
 - Test pass rate for feature toggle tests
 - Retry attempt frequency (target: <5%)
 - Polling iteration count (typical: 1-3)
@@ -307,11 +344,13 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 ### Alerting Thresholds
 
 **Backend Alerts:**
+
 - P99 > 500ms → Investigate regression (2.5x slower than optimized)
 - Error rate > 1% → Check database health
 - Query count > 1 for GET → N+1 pattern reintroduced
 
 **E2E Alerts:**
+
 - Test pass rate < 95% → Check for new flakiness
 - Timeout errors > 0 → Investigate CI environment
 - Retry rate > 10% → Investigate transient failure source
@@ -319,10 +358,12 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 ### Dashboard
 
 **CI Metrics:**
+
 - Link: `.github/workflows/e2e-tests.yml` artifacts
 - Extracts `[METRICS]` logs for P50/P95/P99 analysis
 
 **Backend Logs:**
+
 - Docker container logs with `[METRICS]` tag
 - Example: `[METRICS] GET /feature-flags: 120ms`
 
@@ -331,15 +372,18 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 ### High Latency (P99 > 500ms)
 
 **Symptoms:**
+
 - E2E tests timing out
 - Backend logs show latency spikes
 
 **Diagnosis:**
+
 1. Check query count: `grep "SELECT" backend/logs/query.log`
 2. Verify batch query: Should see `WHERE key IN (...)`
 3. Check transaction wrapping: Should see single `BEGIN ... COMMIT`
 
 **Remediation:**
+
 - If N+1 pattern detected: Verify batch query implementation
 - If transaction missing: Verify transaction wrapping
 - If database locks: Check concurrent access patterns
@@ -347,15 +391,18 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 ### Transaction Rollback Errors
 
 **Symptoms:**
+
 - PUT requests return 500 errors
 - Backend logs show transaction failure
 
 **Diagnosis:**
+
 1. Check error message: `grep "Failed to update feature flags" backend/logs/app.log`
 2. Verify database constraints: Unique key constraints, foreign keys
 3. Check database connectivity: Connection pool exhaustion
 
 **Remediation:**
+
 - If constraint violation: Fix invalid flag key or value
 - If connection issue: Tune connection pool settings
 - If deadlock: Analyze concurrent access patterns
@@ -363,15 +410,18 @@ go test ./internal/api/handlers/ -bench=Benchmark.*Flags -benchmem -run=^$
 ### E2E Test Flakiness
 
 **Symptoms:**
+
 - Tests pass locally, fail in CI
 - Timeout errors in Playwright logs
 
 **Diagnosis:**
+
 1. Check backend latency: `grep "[METRICS]" ci-logs.txt`
 2. Verify retry logic: Should see retry attempts in logs
 3. Check polling behavior: Should see multiple GET requests
 
 **Remediation:**
+
 - If backend slow: Investigate CI environment (disk I/O, CPU)
 - If no retries: Verify `retryAction()` wrapper in test
 - If no polling: Verify `waitForFeatureFlagPropagation()` usage

docs/plans/current_spec.md

@@ -1,412 +1,592 @@
-# CWE-614 Remediation — Sensitive Cookie Without 'Secure' Attribute
+# Ntfy Notification Provider — Implementation Specification
 
-**Date**: 2026-03-21
-**Scope**: `go/cookie-secure-not-set` CodeQL finding in `backend/internal/api/handlers/auth_handler.go`
-**Status**: Draft — Awaiting implementation
+## 1. Introduction
+
+### Overview
+
+Add **Ntfy** (<https://ntfy.sh>) as a notification provider in Charon, following
+the same wrapper pattern used by Gotify, Telegram, Slack, and Pushover. Ntfy is
+an HTTP-based pub/sub notification service that supports self-hosted and
+cloud-hosted instances. Users publish messages by POSTing JSON to a topic URL,
+optionally with an auth token.
+
+### Objectives
+
+1. Users can create/edit/delete an Ntfy notification provider via the Management UI.
+2. Ntfy dispatches support all three template modes (minimal, detailed, custom).
+3. Ntfy respects the global notification engine kill-switch and its own per-provider feature flag.
+4. Security: auth tokens are stored securely (never exposed in API responses or logs).
+5. Full E2E and unit test coverage matching the existing provider test suite.
 
 ---
 
-## 1. Problem Statement
+## 2. Research Findings
 
-### CWE-614 Description
+### Existing Architecture
 
-CWE-614 (*Sensitive Cookie Without 'Secure' Attribute*) describes the vulnerability where a
-session or authentication cookie is issued without the `Secure` attribute. Without this attribute,
-browsers are permitted to transmit the cookie over unencrypted HTTP connections, exposing the
-token to network interception. A single cleartext transmission of an `auth_token` cookie is
-sufficient for session hijacking.
+Charon's notification engine does **not** use a Go interface pattern. Instead, it
+routes on string type values (`"discord"`, `"gotify"`, `"webhook"`, etc.) across
+~15 switch/case + hardcoded lists in both backend and frontend.
 
-### CodeQL Rule
+**Key code paths per provider type:**
 
-The CodeQL query `go/cookie-secure-not-set` (security severity: **warning**) flags any call to
-`http.SetCookie` or Gin's `c.SetCookie` where static analysis can prove there exists an execution
-path in which the `secure` parameter evaluates to `false`. The rule does not require the path to
-be reachable in production — it fires on reachability within Go's control-flow graph.
+| Layer | Location | Mechanism |
+|-------|----------|-----------|
+| Model | `backend/internal/models/notification_provider.go` | Generic — no per-type changes needed |
+| Service — type allowlist | `notification_service.go:139` `isSupportedNotificationProviderType()` | `switch` on type string |
+| Service — flag routing | `notification_service.go:148` `isDispatchEnabled()` | `switch` → feature flag lookup |
+| Service — dispatch | `notification_service.go:381` `sendJSONPayload()` | Type-specific validation + URL / header construction |
+| Feature flags | `notifications/feature_flags.go` | Const strings for settings DB keys |
+| Router | `notifications/router.go:10` `ShouldUseNotify()` | `switch` on type → flag map lookup |
+| Handler — create validation | `notification_provider_handler.go:185` | Hardcoded `!=` chain |
+| Handler — update validation | `notification_provider_handler.go:245` | Hardcoded `!=` chain |
+| Handler — URL validation | `notification_provider_handler.go:372` | Slack special-case (optional URL) |
+| Frontend — type array | `api/notifications.ts:3` | `SUPPORTED_NOTIFICATION_PROVIDER_TYPES` const |
+| Frontend — sanitize | `api/notifications.ts` `sanitizeProviderForWriteAction()` | Token mapping per type |
+| Frontend — form | `pages/Notifications.tsx` | `<option>`, URL label, token field, placeholder, `supportsJSONTemplates()`, `normalizeProviderPayloadForSubmit()`, `useEffect` token cleanup |
+| Frontend — unit test mock | `pages/__tests__/Notifications.test.tsx` | Mock of `SUPPORTED_NOTIFICATION_PROVIDER_TYPES` |
+| i18n | `locales/{en,de,fr,zh,es}/translation.json` | `notificationProviders.*` keys |
 
-### SARIF Finding
+### Ntfy HTTP API Reference
 
-The SARIF file `codeql-results-go.sarif` contains one result for `go/cookie-secure-not-set`:
+Ntfy accepts a JSON POST to a topic URL:
 
-| Field | Value |
-|---|---|
-| Rule ID | `go/cookie-secure-not-set` |
-| Message | "Cookie does not set Secure attribute to true." |
-| File | `internal/api/handlers/auth_handler.go` |
-| Region | Lines 152–160, columns 2–3 |
-| CWE tag | `external/cwe/cwe-614` |
-| CVSS severity | Warning |
+```
+POST https://ntfy.sh/my-topic
+Authorization: Bearer tk_abc123   # optional
+Content-Type: application/json
 
-The flagged region is the `c.SetCookie(...)` call inside `setSecureCookie`, where the `secure`
-variable (sourced from a `bool` modified at line 140 via `secure = false`) can carry `false`
-through the call.
+{
+  "topic": "my-topic",       // optional if encoded in URL
+  "message": "Hello!",       // required
+  "title": "Alert Title",    // optional
+  "priority": 3,             // optional (1-5, default 3)
+  "tags": ["warning"]        // optional
+}
+```
+
+This maps directly to the Gotify dispatch pattern: POST JSON to `p.URL` with an
+optional `Authorization: Bearer <token>` header.
 
 ---
 
-## 2. Root Cause Analysis
+## 3. Technical Specifications
 
-### The Offending Logic in `setSecureCookie`
+### 3.1 Provider Interface / Contract (Type Registration)
 
-`setSecureCookie` (auth_handler.go, line 133) constructs the `Secure` attribute value using
-runtime heuristics:
+Ntfy uses type string `"ntfy"`. Every switch/case and hardcoded type list must
+include this value. The following table is the exhaustive changeset:
+
+| # | File | Function / Location | Change |
+|---|------|---------------------|--------|
+| 1 | `backend/internal/services/notification_service.go` | `isSupportedNotificationProviderType()` ~L139 | Add `case "ntfy": return true` |
+| 2 | `backend/internal/services/notification_service.go` | `isDispatchEnabled()` ~L148 | Add `case "ntfy":` with `FlagNtfyServiceEnabled`, default `true` |
+| 3 | `backend/internal/services/notification_service.go` | `sendJSONPayload()` — validation block ~L460 | Add ntfy JSON validation: require `"message"` field |
+| 4 | `backend/internal/services/notification_service.go` | `sendJSONPayload()` — dispatch routing ~L530 | Add ntfy dispatch block (URL from `p.URL`, optional Bearer auth from `p.Token`) |
+| 5 | `backend/internal/services/notification_service.go` | `supportsJSONTemplates()` ~L131 | Add `case "ntfy": return true` — gates `SendExternal()` JSON dispatch path |
+| 6 | `backend/internal/services/notification_service.go` | `sendJSONPayload()` — outer gating condition ~L525 | Add `\|\| providerType == "ntfy"` to the if-chain that enters the dispatch block |
+| 7 | `backend/internal/services/notification_service.go` | `CreateProvider()` — token-clearing condition ~L851 | Add `&& provider.Type != "ntfy"` (and `&& provider.Type != "pushover"` — existing bug fix) to prevent token being silently cleared on creation |
+| 8 | `backend/internal/services/notification_service.go` | `UpdateProvider()` — token preservation ~L886 | Add `\|\| provider.Type == "ntfy"` (and `\|\| provider.Type == "pushover"` — existing bug fix) to preserve token on update when not re-entered |
+| 9 | `backend/internal/notifications/feature_flags.go` | Constants | Add `FlagNtfyServiceEnabled = "feature.notifications.service.ntfy.enabled"` |
+| 10 | `backend/internal/notifications/router.go` | `ShouldUseNotify()` | Add `case "ntfy": return flags[FlagNtfyServiceEnabled]` |
+| 11 | `backend/internal/api/handlers/notification_provider_handler.go` | `Create()` ~L185 | Add `&& providerType != "ntfy"` to validation chain |
+| 12 | `backend/internal/api/handlers/notification_provider_handler.go` | `Update()` ~L245 | Add `&& providerType != "ntfy"` to validation chain |
+| 13 | `backend/internal/api/handlers/notification_provider_handler.go` | `Update()` — token preservation ~L250 | Add `\|\| providerType == "ntfy"` to the condition that preserves existing token when update payload omits it |
+| 14 | `frontend/src/api/notifications.ts` | `SUPPORTED_NOTIFICATION_PROVIDER_TYPES` | Add `'ntfy'` to array |
+| 15 | `frontend/src/api/notifications.ts` | `sanitizeProviderForWriteAction()` | Add `'ntfy'` to token-bearing types |
+| 16 | `frontend/src/pages/Notifications.tsx` | `supportsJSONTemplates()` | Add `|| t === 'ntfy'` |
+| 17 | `frontend/src/pages/Notifications.tsx` | `normalizeProviderPayloadForSubmit()` | Add `'ntfy'` to token-bearing types |
+| 18 | `frontend/src/pages/Notifications.tsx` | `useEffect` token cleanup | Add `type !== 'ntfy'` to the cleanup condition |
+| 19 | `frontend/src/pages/Notifications.tsx` | `<select>` dropdown | Add `<option value="ntfy">Ntfy</option>` |
+| 20 | `frontend/src/pages/Notifications.tsx` | URL label ternary | Ntfy uses default URL/Webhook label — no special label needed, falls through to default |
+| 21 | `frontend/src/pages/Notifications.tsx` | Token field visibility | Add `isNtfy` to `(isGotify \|\| isTelegram \|\| isSlack \|\| isPushover \|\| isNtfy)` |
+| 22 | `frontend/src/pages/Notifications.tsx` | Token field label | Add `isNtfy ? t('notificationProviders.ntfyAccessToken') : ...` |
+| 23 | `frontend/src/pages/Notifications.tsx` | URL placeholder | Add ntfy case: `type === 'ntfy' ? 'https://ntfy.sh/my-topic'` |
+| 24 | `frontend/src/pages/Notifications.tsx` | URL validation `required` | Ntfy requires URL — no change (default requires URL) |
+| 25 | `frontend/src/pages/Notifications.tsx` | URL validation `validate` | Ntfy uses standard URL validation — no change (default validates URL) |
+| 26 | `frontend/src/pages/Notifications.tsx` | `isNtfy` const | Add `const isNtfy = type === 'ntfy';` near L151 |
+| 27 | `frontend/src/pages/__tests__/Notifications.test.tsx` | Mock array | Add `'ntfy'` to mock `SUPPORTED_NOTIFICATION_PROVIDER_TYPES` |
+| 28 | `tests/settings/notifications.spec.ts` | Provider type options assertion ~L297 | Change `toHaveCount(7)` → `toHaveCount(8)`, add `'Ntfy'` to `toHaveText()` array |
+
+### 3.2 Backend Implementation Details
+
+#### 3.2.1 Feature Flag
+
+**File:** `backend/internal/notifications/feature_flags.go`
 
 ```go
-secure := true
-sameSite := http.SameSiteStrictMode
-if scheme != "https" {
-    sameSite = http.SameSiteLaxMode
-    if isLocalRequest(c) {
-        secure = false   // ← line 140: CWE-614 root cause
+const FlagNtfyServiceEnabled = "feature.notifications.service.ntfy.enabled"
+```
+
+#### 3.2.2 Router
+
+**File:** `backend/internal/notifications/router.go`
+
+Add in `ShouldUseNotify()` switch:
+
+```go
+case "ntfy":
+    return flags[FlagNtfyServiceEnabled]
+```
+
+#### 3.2.3 Service — Type Registration
+
+**File:** `backend/internal/services/notification_service.go`
+
+In `isSupportedNotificationProviderType()`:
+
+```go
+case "ntfy":
+    return true
+```
+
+In `isDispatchEnabled()`:
+
+```go
+case "ntfy":
+    return getFeatureFlagValue(db, notifications.FlagNtfyServiceEnabled, true)
+```
+
+#### 3.2.4 Service — JSON Validation (sendJSONPayload)
+
+In the service-specific validation block (~L460), add before the default case:
+
+```go
+case "ntfy":
+    if _, ok := payload["message"]; !ok {
+        return fmt.Errorf("ntfy payload must include a 'message' field")
     }
+```
+
+> **Note:** Ntfy `priority` (1–5) can be set via custom templates by including a
+> `"priority"` field in the JSON. No code change is needed — the validation only
+> requires `"message"`.
+
+#### 3.2.5 Service — supportsJSONTemplates + Outer Gating + Dispatch Routing
+
+**supportsJSONTemplates()** (~L131): Add `"ntfy"` so `SendExternal()` dispatches
+via the JSON path:
+
+```go
+case "ntfy":
+    return true
+```
+
+**Outer gating condition** (~L525): The dispatch block is entered only when the
+provider type matches an `if/else if` chain. The actual code uses `if` chains,
+**not** `switch/case`. Add ntfy:
+
+```go
+// Before (actual code structure — NOT switch/case):
+if providerType == "gotify" || providerType == "webhook" || providerType == "telegram" || providerType == "slack" || providerType == "pushover" {
+
+// After:
+if providerType == "gotify" || providerType == "webhook" || providerType == "telegram" || providerType == "slack" || providerType == "pushover" || providerType == "ntfy" {
+```
+
+**Dispatch routing** (~L540): Inside the dispatch block, add an ntfy branch
+using the same `if/else if` pattern as existing providers:
+
+```go
+// Actual code uses if/else if — NOT switch/case:
+} else if providerType == "ntfy" {
+    dispatchURL = p.URL
+    if strings.TrimSpace(p.Token) != "" {
+        headers["Authorization"] = "Bearer " + strings.TrimSpace(p.Token)
+    }
+```
+
+Then the existing `httpWrapper.Send(dispatchURL, headers, body)` call handles dispatch.
+
+#### 3.2.6 Service — CreateProvider / UpdateProvider Token Preservation
+
+**File:** `backend/internal/services/notification_service.go`
+
+**`CreateProvider()` (~L851)** — token-clearing condition currently omits both
+ntfy and pushover, silently clearing tokens on creation:
+
+```go
+// Before:
+if provider.Type != "gotify" && provider.Type != "telegram" && provider.Type != "slack" {
+    provider.Token = ""
+}
+
+// After (adds ntfy + fixes existing pushover bug):
+if provider.Type != "gotify" && provider.Type != "telegram" && provider.Type != "slack" && provider.Type != "pushover" && provider.Type != "ntfy" {
+    provider.Token = ""
 }
 ```
 
-When both conditions hold — `requestScheme(c)` returns `"http"` AND `isLocalRequest(c)` returns
-`true` — the variable `secure` is assigned `false`. This value then flows unmodified into:
+**`UpdateProvider()` (~L886)** — token preservation condition currently omits
+both ntfy and pushover, silently clearing tokens on update:
 
 ```go
-c.SetCookie( // codeql[go/cookie-secure-not-set]
-    name, value, maxAge, "/", domain,
-    secure, // ← false in the local-HTTP branch
-    true,
-)
-```
+// Before:
+if provider.Type == "gotify" || provider.Type == "telegram" || provider.Type == "slack" {
+    if strings.TrimSpace(provider.Token) == "" {
+        provider.Token = existing.Token
+    }
+} else {
+    provider.Token = ""
+}
 
-CodeQL's dataflow engine traces the assignment on line 140 to the parameter on line 159 and emits
-the finding. The `// codeql[go/cookie-secure-not-set]` inline suppression comment was added
-alongside the logic, but the SARIF file pre-dates the suppression and the CI continues to report
-the finding — indicating either that the suppression was committed after the SARIF was captured
-in the repository, or that GitHub Code Scanning's alert dismissal has not processed it.
-
-### Why the Suppression Is Insufficient
-
-Inline suppression via `// codeql[rule-id]` tells CodeQL to dismiss the alert at that specific
-callsite. It does not eliminate the code path that creates the security risk; it merely hides the
-symptom. In a codebase with Charon's security posture (full supply-chain auditing, SBOM
-generation, weekly CVE scanning), suppressing rather than fixing a cookie security issue is the
-wrong philosophy. The authentic solution is to remove the offending branch.
-
-### What `isLocalRequest` Detects
-
-`isLocalRequest(c *gin.Context) bool` returns `true` if any of the following resolve to a local
-or RFC 1918 private address: `c.Request.Host`, `c.Request.URL.Host`, the `Origin` header, the
-`Referer` header, or any comma-delimited value in `X-Forwarded-Host`. It delegates to
-`isLocalOrPrivateHost(host string) bool`, which checks for `"localhost"` (case-insensitive),
-`ip.IsLoopback()`, or `ip.IsPrivate()` per the Go `net` package (10.0.0.0/8, 172.16.0.0/12,
-192.168.0.0/16, ::1, fc00::/7).
-
-### Why `secure = false` Was Introduced
-
-The intent was to permit Charon to be accessed over HTTP on private networks (e.g., a developer
-reaching `http://192.168.1.50:8080`). Browsers reject cookies with the `Secure` attribute on
-non-HTTPS connections for non-localhost hosts, so setting `Secure = true` on a response to a
-`192.168.x.x` HTTP request causes the browser to silently discard the cookie, breaking
-authentication. The original author therefore conditionally disabled the `Secure` flag for these
-deployments.
-
-### Why This Is Now Wrong for Charon
-
-Charon is a security-oriented reverse proxy manager designed to sit behind Caddy, which always
-provides TLS termination in any supported deployment. The HTTP-on-private-IP access pattern breaks
-down into three real-world scenarios:
-
-1. **Local development (`http://localhost:8080`)** — All major browsers (Chrome 66+, Firefox 75+,
-   Safari 14+) implement the *localhost exception*: the `Secure` cookie attribute is honoured and
-   the cookie is accepted and retransmitted over HTTP to localhost. Setting `Secure = true` causes
-   zero breakage here.
-
-2. **Docker-internal container access (`http://172.x.x.x`)** — Charon is never reached directly
-   from within the Docker network by a browser; health probes and inter-container calls do not use
-   cookies. No breakage.
-
-3. **Private-IP direct browser access (`http://192.168.x.x:8080`)** — This is explicitly
-   unsupported as an end-user deployment mode. The Charon `ARCHITECTURE.md` describes the only
-   supported path as via Caddy (HTTPS) or `localhost`. Setting `Secure = true` on these responses
-   means the browser ignores the cookie; but this deployment pattern should not exist regardless.
-
-The conclusion: removing `secure = false` unconditionally is both correct and safe for all
-legitimate Charon deployments.
-
----
-
-## 3. Affected Files
-
-### Primary Change
-
-| File | Function | Lines | Nature |
-|---|---|---|---|
-| `backend/internal/api/handlers/auth_handler.go` | `setSecureCookie` | 128–162 | Delete `secure = false` branch; update docstring; remove suppression comment |
-
-No other file in the backend sets cookies directly. Every cookie write flows through
-`setSecureCookie` or its thin wrapper `clearSecureCookie`. The complete call graph:
-
-- `setSecureCookie` — canonical cookie writer (line 133)
-- `clearSecureCookie` → `setSecureCookie(c, name, "", -1)` (line 166)
-- `AuthHandler.Login` → `setSecureCookie(c, "auth_token", token, 3600*24)` (line 188)
-- `AuthHandler.Logout` → `clearSecureCookie(c, "auth_token")`
-- `AuthHandler.Refresh` → `setSecureCookie(c, "auth_token", token, 3600*24)` (line 252)
-
-`clearSecureCookie` requires no changes; it already delegates through `setSecureCookie`.
-
-### Test File Changes
-
-| File | Test Function | Line | Change |
-|---|---|---|---|
-| `backend/internal/api/handlers/auth_handler_test.go` | `TestSetSecureCookie_HTTP_Loopback_Insecure` | 115 | `assert.False` → `assert.True` |
-| `backend/internal/api/handlers/auth_handler_test.go` | `TestSetSecureCookie_HTTP_PrivateIP_Insecure` | 219 | `assert.False` → `assert.True` |
-| `backend/internal/api/handlers/auth_handler_test.go` | `TestSetSecureCookie_HTTP_10Network_Insecure` | 237 | `assert.False` → `assert.True` |
-| `backend/internal/api/handlers/auth_handler_test.go` | `TestSetSecureCookie_HTTP_172Network_Insecure` | 255 | `assert.False` → `assert.True` |
-| `backend/internal/api/handlers/auth_handler_test.go` | `TestSetSecureCookie_HTTP_IPv6ULA_Insecure` | 291 | `assert.False` → `assert.True` |
-
-The five tests named `*_Insecure` were authored to document the now-removed behaviour; their
-assertions flip from `False` to `True`. Their names remain unchanged — renaming is cosmetic and
-out of scope for a security fix.
-
-Tests that must remain unchanged:
-
-- `TestSetSecureCookie_HTTPS_Strict` — asserts `True`; unaffected.
-- `TestSetSecureCookie_HTTP_Lax` — asserts `True`; unaffected (192.0.2.0/24 is TEST-NET-1, not
-  an RFC 1918 private range, so `isLocalRequest` already returned `false` here).
-- `TestSetSecureCookie_ForwardedHTTPS_LocalhostForcesInsecure` — asserts `True`; unaffected.
-- `TestSetSecureCookie_ForwardedHTTPS_LoopbackForcesInsecure` — asserts `True`; unaffected.
-- `TestSetSecureCookie_ForwardedHostLocalhostForcesInsecure` — asserts `True`; unaffected.
-- `TestSetSecureCookie_OriginLoopbackForcesInsecure` — asserts `True`; unaffected.
-- `TestSetSecureCookie_HTTPS_PrivateIP_Secure` — asserts `True`; unaffected.
-- `TestSetSecureCookie_HTTP_PublicIP_Secure` — asserts `True`; unaffected.
-
----
-
-## 4. Implementation Details
-
-### 4.1 Changes to `setSecureCookie` in `auth_handler.go`
-
-**Before** (lines 128–162):
-
-```go
-// setSecureCookie sets an auth cookie with security best practices
-// - HttpOnly: prevents JavaScript access (XSS protection)
-// - Secure: true for HTTPS; false for local/private network HTTP requests
-// - SameSite: Lax for any local/private-network request (regardless of scheme),
-//   Strict otherwise (public HTTPS only)
-func setSecureCookie(c *gin.Context, name, value string, maxAge int) {
-	scheme := requestScheme(c)
-	secure := true
-	sameSite := http.SameSiteStrictMode
-	if scheme != "https" {
-		sameSite = http.SameSiteLaxMode
-		if isLocalRequest(c) {
-			secure = false
-		}
-	}
-
-	if isLocalRequest(c) {
-		sameSite = http.SameSiteLaxMode
-	}
-
-	// Use the host without port for domain
-	domain := ""
-
-	c.SetSameSite(sameSite)
-	// secure is intentionally false for local/private network HTTP requests; always true for external or HTTPS requests.
-	c.SetCookie( // codeql[go/cookie-secure-not-set]
-		name,   // name
-		value,  // value
-		maxAge, // maxAge in seconds
-		"/",    // path
-		domain, // domain (empty = current host)
-		secure, // secure
-		true,   // httpOnly (no JS access)
-	)
+// After (adds ntfy + fixes existing pushover bug):
+if provider.Type == "gotify" || provider.Type == "telegram" || provider.Type == "slack" || provider.Type == "pushover" || provider.Type == "ntfy" {
+    if strings.TrimSpace(provider.Token) == "" {
+        provider.Token = existing.Token
+    }
+} else {
+    provider.Token = ""
 }
 ```
 
-**After**:
+> **Bonus bugfix:** The `pushover` additions fix a pre-existing bug where
+> pushover tokens were silently cleared on create and update. This will be noted
+> in the commit message for Commit 3.
+
+#### 3.2.7 Handler — Type Validation + Token Preservation
+
+**File:** `backend/internal/api/handlers/notification_provider_handler.go`
+
+**`Create()` (~L185)** and **`Update()` (~L245)** type-validation chains:
+Add `&& providerType != "ntfy"` so ntfy passes the supported-type check.
+
+**`Update()` token preservation (~L250)**: The handler has its own token
+preservation condition that runs before calling the service. Add ntfy:
 
 ```go
-// setSecureCookie sets an auth cookie with security best practices
-// - HttpOnly: prevents JavaScript access (XSS protection)
-// - Secure: always true; the localhost exception in Chrome, Firefox, and Safari
-//   permits Secure cookies over HTTP to localhost/127.0.0.1 without issue
-// - SameSite: Lax for any local/private-network request (regardless of scheme),
-//   Strict otherwise (public HTTPS only)
-func setSecureCookie(c *gin.Context, name, value string, maxAge int) {
-	scheme := requestScheme(c)
-	sameSite := http.SameSiteStrictMode
-	if scheme != "https" || isLocalRequest(c) {
-		sameSite = http.SameSiteLaxMode
-	}
+// Before:
+if (providerType == "gotify" || providerType == "telegram" || providerType == "slack" || providerType == "pushover") && strings.TrimSpace(req.Token) == "" {
+    req.Token = existing.Token
+}
 
-	// Use the host without port for domain
-	domain := ""
-
-	c.SetSameSite(sameSite)
-	c.SetCookie(
-		name,   // name
-		value,  // value
-		maxAge, // maxAge in seconds
-		"/",    // path
-		domain, // domain (empty = current host)
-		true,   // secure (always; satisfies CWE-614)
-		true,   // httpOnly (no JS access)
-	)
+// After:
+if (providerType == "gotify" || providerType == "telegram" || providerType == "slack" || providerType == "pushover" || providerType == "ntfy") && strings.TrimSpace(req.Token) == "" {
+    req.Token = existing.Token
 }
 ```
 
-**What changed**:
+No URL validation special-case is needed for Ntfy (URL is required and follows
+standard http/https format).
 
-1. The `secure := true` variable is removed entirely; `true` is now a literal at the callsite,
-   making the intent unmistakable to both humans and static analysis tools.
-2. The `if scheme != "https" { ... if isLocalRequest(c) { secure = false } }` block is replaced
-   by a single `if scheme != "https" || isLocalRequest(c)` guard for the `sameSite` value only.
-   The two previously separate `isLocalRequest` calls collapse into one.
-3. The `// secure is intentionally false...` comment is removed — it described dead logic.
-4. The `// codeql[go/cookie-secure-not-set]` inline suppression is removed — it is no longer
-   needed and should not persist as misleading dead commentary.
-5. The function's docstring bullet for `Secure:` is updated to reflect the always-true policy
-   and cite the browser localhost exception.
+### 3.3 Frontend Implementation Details
 
-### 4.2 Changes to `auth_handler_test.go`
+#### 3.3.1 API Client
 
-Five `assert.False(t, cookie.Secure)` assertions become `assert.True(t, cookie.Secure)`.
-The SameSite assertions on the lines immediately following each are correct and untouched.
+**File:** `frontend/src/api/notifications.ts`
 
-| Line | Before | After |
-|---|---|---|
-| 115 | `assert.False(t, cookie.Secure)` | `assert.True(t, cookie.Secure)` |
-| 219 | `assert.False(t, cookie.Secure)` | `assert.True(t, cookie.Secure)` |
-| 237 | `assert.False(t, cookie.Secure)` | `assert.True(t, cookie.Secure)` |
-| 255 | `assert.False(t, cookie.Secure)` | `assert.True(t, cookie.Secure)` |
-| 291 | `assert.False(t, cookie.Secure)` | `assert.True(t, cookie.Secure)` |
+```typescript
+export const SUPPORTED_NOTIFICATION_PROVIDER_TYPES = [
+  'discord', 'gotify', 'webhook', 'email', 'telegram', 'slack', 'pushover', 'ntfy'
+] as const;
+```
 
-### 4.3 No Changes Required
+In `sanitizeProviderForWriteAction()`, add `'ntfy'` to the set of token-bearing
+types so that the token field is properly mapped on create/update.
 
-The following functions are call-through wrappers or callers of `setSecureCookie` and require
-zero modification:
+#### 3.3.2 Notifications Page
 
-- `clearSecureCookie` — its contract ("remove the cookie") is satisfied by any `maxAge = -1`
-  call, regardless of the `Secure` attribute value.
-- `AuthHandler.Login`, `AuthHandler.Logout`, `AuthHandler.Refresh` — callsites are unchanged.
-- `isLocalRequest`, `isLocalOrPrivateHost`, `requestScheme`, `normalizeHost`, `originHost` —
-  all remain in use for the `sameSite` determination.
-- `codeql-config.yml` — no query exclusions are needed; the root cause is fixed in code.
+**File:** `frontend/src/pages/Notifications.tsx`
+
+| Area | Change |
+|------|--------|
+| Type boolean | Add `const isNtfy = type === 'ntfy';` |
+| `<select>` | Add `<option value="ntfy">Ntfy</option>` after Pushover |
+| Token visibility | Change `(isGotify \|\| isTelegram \|\| isSlack \|\| isPushover)` to `(isGotify \|\| isTelegram \|\| isSlack \|\| isPushover \|\| isNtfy)` in 3 places: token field visibility, `normalizeProviderPayloadForSubmit()`, and `useEffect` token cleanup |
+| Token label | Add `isNtfy ? t('notificationProviders.ntfyAccessToken') : ...` in the ternary chain |
+| Token placeholder | Add ntfy case: `isNtfy ? t('notificationProviders.ntfyAccessTokenPlaceholder')` |
+| URL label | Consider using `t('notificationProviders.ntfyTopicUrl')` (`"Topic URL"`) for a more descriptive label when ntfy is selected, instead of the default `"URL / Webhook URL"` |
+| URL placeholder | Add `type === 'ntfy' ? 'https://ntfy.sh/my-topic'` in the ternary chain |
+| `supportsJSONTemplates()` | Add `|| t === 'ntfy'` |
+
+#### 3.3.3 i18n Strings
+
+**Files:** `frontend/src/locales/{en,de,fr,zh,es}/translation.json`
+
+Add to the `notificationProviders` section (after `pushoverUserKeyHelp`):
+
+| Key | English Value |
+|-----|---------------|
+| `ntfy` | `"Ntfy"` |
+| `ntfyAccessToken` | `"Access Token (optional)"` |
+| `ntfyAccessTokenPlaceholder` | `"Enter your Ntfy access token"` |
+| `ntfyAccessTokenHelp` | `"Required for password-protected topics on self-hosted instances. Not needed for public ntfy.sh topics. The token is stored securely and separately."` |
+| `ntfyTopicUrl` | `"Topic URL"` |
+
+For non-English locales, the keys should be added with English fallback values
+(the community can translate later).
+
+#### 3.3.4 Unit Test Mock + E2E Assertion Update
+
+**File:** `frontend/src/pages/__tests__/Notifications.test.tsx`
+
+Update the mocked `SUPPORTED_NOTIFICATION_PROVIDER_TYPES` array to include `'ntfy'`.
+Update the test `'shows supported provider type options'` to expect 8 options instead of 7.
+
+**File:** `tests/settings/notifications.spec.ts`
+
+Update the E2E assertion at ~L297:
+- `toHaveCount(7)` → `toHaveCount(8)`
+- Add `'Ntfy'` to the `toHaveText()` array: `['Discord', 'Gotify', 'Generic Webhook', 'Email', 'Telegram', 'Slack', 'Pushover', 'Ntfy']`
+
+### 3.4 Database Migration
+
+**No schema changes required.** The existing `NotificationProvider` GORM model
+already has all the fields Ntfy needs:
+
+| Ntfy Concept | Model Field |
+|--------------|-------------|
+| Topic URL | `URL` |
+| Auth token | `Token` (json:"-") |
+| Has token indicator | `HasToken` (computed, gorm:"-") |
+
+GORM AutoMigrate handles migrations from model definitions. No migration file
+is needed.
+
+### 3.5 Data Flow Diagram
+
+```
+User creates Ntfy provider via UI
+  -> POST /api/v1/notifications/providers { type: "ntfy", url: "https://ntfy.sh/alerts", token: "tk_..." }
+  -> Handler validates type is in allowed list
+  -> Service stores provider in SQLite (token encrypted at rest)
+
+Event triggers notification dispatch:
+  -> SendExternal() filters enabled providers by event type preferences
+  -> isDispatchEnabled("ntfy") -> checks FlagNtfyServiceEnabled setting
+  -> sendJSONPayload() renders template -> validates payload has "message" field
+  -> Constructs dispatch: POST to p.URL with Authorization: Bearer <token> header
+  -> httpWrapper.Send(dispatchURL, headers, body) -> HTTP POST to Ntfy server
+```
 
 ---
 
-## 5. Test Coverage Requirements
+## 4. Implementation Plan
 
-### 5.1 Existing Coverage — Sufficient After Amendment
+### Phase 1: Playwright E2E Tests (Test-First)
 
-The five amended tests continue to exercise the local-HTTP branch of `setSecureCookie`:
+Write E2E tests that define the expected UI/UX behavior for Ntfy before
+implementing the feature. Tests will initially fail and pass after implementation.
 
-- They confirm `SameSiteLaxMode` is still applied for local/private-IP HTTP requests.
-- They now additionally confirm `Secure = true` even on those requests.
+**Deliverables:**
 
-No new test functions are required; the amendment *restores* the existing tests to accuracy.
+| File | Description |
+|------|-------------|
+| `tests/settings/ntfy-notification-provider.spec.ts` | New file — form rendering, CRUD, token security, field toggling |
+| `tests/settings/notifications-payload.spec.ts` | Add Ntfy to payload contract validation matrix |
+| `tests/settings/notifications.spec.ts` | Update provider type dropdown assertions: `toHaveCount(7)` → `toHaveCount(8)`, add `'Ntfy'` to `toHaveText()` array |
 
-### 5.2 Regression Check
+**Test structure** (following telegram/pushover/slack pattern):
 
-After the change, run the full `handlers` package test suite:
+1. Form Rendering
+   - Show token field when ntfy type selected
+   - Verify token label shows "Access Token (optional)"
+   - Verify URL placeholder shows "https://ntfy.sh/my-topic"
+   - Verify JSON template section is shown for ntfy
+   - Toggle fields when switching between ntfy and discord
+2. CRUD Operations
+   - Create ntfy provider with URL + token
+   - Create ntfy provider with URL only (no token)
+   - Edit ntfy provider (token field shows "Leave blank to keep")
+   - Delete ntfy provider
+3. Token Security
+   - Verify token field is `type="password"`
+   - Verify token is not exposed in API response row
+4. Payload Contract
+   - Valid ntfy payload with message field accepted
+   - Missing message field rejected
 
-```bash
-cd backend && go test ./internal/api/handlers/... -run TestSetSecureCookie -v
-```
+### Phase 2: Backend Implementation
 
-All tests matching `TestSetSecureCookie*` must pass. Pay particular attention to:
+**Deliverables:**
 
-- `TestSetSecureCookie_HTTP_Loopback_Insecure` — `Secure = true`, `SameSite = Lax`
-- `TestSetSecureCookie_HTTPS_Strict` — `Secure = true`, `SameSite = Strict`
-- `TestSetSecureCookie_HTTP_PublicIP_Secure` — `Secure = true`, `SameSite = Lax`
+| # | File | Changes |
+|---|------|---------|
+| 1 | `backend/internal/notifications/feature_flags.go` | Add `FlagNtfyServiceEnabled` constant |
+| 2 | `backend/internal/notifications/router.go` | Add `"ntfy"` case in `ShouldUseNotify()` |
+| 3 | `backend/internal/services/notification_service.go` | Add `"ntfy"` to `isSupportedNotificationProviderType()`, `isDispatchEnabled()`, `supportsJSONTemplates()`, outer gating condition, dispatch routing, `CreateProvider()` token chain, `UpdateProvider()` token chain. Fix pushover token-clearing bug in same conditions. |
+| 4 | `backend/internal/api/handlers/notification_provider_handler.go` | Add `"ntfy"` to Create/Update type validation + Update token preservation |
 
-### 5.3 No New Tests
+**Backend Unit Tests:**
 
-A new test asserting `Secure = true` for all request types would be redundant — the amended
-assertions across 5 existing tests already cover loopback, private-IPv4 (three RFC 1918 ranges),
-and IPv6 ULA. There is no behavioural gap that requires new coverage.
+| File | New Tests |
+|------|-----------|
+| `backend/internal/notifications/router_test.go` | `TestShouldUseNotify_Ntfy` — flag on/off |
+| `backend/internal/services/notification_service_test.go` | `TestIsSupportedNotificationProviderType_Ntfy`, `TestIsDispatchEnabled_Ntfy` |
+| `backend/internal/services/notification_service_json_test.go` | `TestSendJSONPayload_Ntfy_Valid`, `TestSendJSONPayload_Ntfy_MissingMessage`, `TestSendJSONPayload_Ntfy_WithToken`, `TestSendJSONPayload_Ntfy_WithoutToken` |
+
+### Phase 3: Frontend Implementation
+
+**Deliverables:**
+
+| # | File | Changes |
+|---|------|---------|
+| 1 | `frontend/src/api/notifications.ts` | Add `'ntfy'` to type array + sanitize function |
+| 2 | `frontend/src/pages/Notifications.tsx` | Add `isNtfy`, dropdown option, token field wiring, URL placeholder, `supportsJSONTemplates()`, `normalizeProviderPayloadForSubmit()`, `useEffect` cleanup |
+| 3 | `frontend/src/locales/en/translation.json` | Add `ntfy*` i18n keys |
+| 4 | `frontend/src/locales/de/translation.json` | Add `ntfy*` i18n keys (English fallback) |
+| 5 | `frontend/src/locales/fr/translation.json` | Add `ntfy*` i18n keys (English fallback) |
+| 6 | `frontend/src/locales/zh/translation.json` | Add `ntfy*` i18n keys (English fallback) |
+| 7 | `frontend/src/locales/es/translation.json` | Add `ntfy*` i18n keys (English fallback) |
+| 8 | `frontend/src/pages/__tests__/Notifications.test.tsx` | Update mock array + option count assertion |
+
+### Phase 4: Integration and Testing
+
+1. Rebuild E2E Docker environment (`docker-rebuild-e2e`).
+2. Run full Playwright suite (Firefox, Chromium, WebKit).
+3. Run backend `go test ./...`.
+4. Run frontend `npm test`.
+5. Run GORM security scanner (changes touch service logic, not models — likely clean).
+6. Verify E2E coverage via Vite dev server mode.
+
+### Phase 5: Documentation and Deployment
+
+1. Update `docs/features.md` — add Ntfy to supported notification providers list.
+2. Update `CHANGELOG.md` — add `feat(notifications): add Ntfy notification provider`.
+
+---
+
+## 5. Acceptance Criteria
+
+| # | Criterion | Validation Method |
+|---|-----------|-------------------|
+| AC-1 | User can select "Ntfy" from the provider type dropdown | E2E: `ntfy-notification-provider.spec.ts` form rendering tests |
+| AC-2 | Topic URL field is required with standard http/https validation | E2E: form validation tests |
+| AC-3 | Access Token field is shown as optional password field | E2E: token field visibility + type="password" check |
+| AC-4 | Token is never exposed in API responses (has_token indicator only) | E2E: token security tests |
+| AC-5 | JSON template section (minimal/detailed/custom) is available | E2E: template section visibility |
+| AC-6 | Ntfy provider can be created, edited, deleted | E2E: CRUD tests |
+| AC-7 | Test notification dispatches to Ntfy topic URL with correct headers | Backend unit test: sendJSONPayload ntfy dispatch |
+| AC-8 | Missing `message` field in payload is rejected | Backend unit test + E2E payload validation |
+| AC-9 | Feature flag `feature.notifications.service.ntfy.enabled` controls dispatch | Backend unit test: isDispatchEnabled + router |
+| AC-10 | All 5 locales have ntfy i18n keys | Manual verification |
+| AC-11 | No GORM security scanner CRITICAL/HIGH findings | GORM scanner `--check` |
 
 ---
 
 ## 6. Commit Slicing Strategy
 
-This remediation ships as a **single commit on a single PR**. It touches exactly two files and
-changes exactly one category of behaviour (the cookie `Secure` attribute). Splitting it would
-create a transient state where the production code and the unit tests are inconsistent.
+### Decision: Single PR
 
-**Commit message**:
+**Rationale:** Ntfy is a self-contained, additive feature that does not touch
+existing provider logic (only adds new cases to existing switch/case and if-chain
+blocks). The changeset is small (~16 files, <300 lines of implementation + ~430
+lines of tests) and stays within a single domain (notifications). A single PR is
+straightforward to review and rollback. One bonus bugfix is included: pushover
+token-clearing in `CreateProvider()`/`UpdateProvider()` is fixed in the same
+lines being modified for ntfy.
 
-```
-fix(auth): always set Secure attribute on auth cookies (CWE-614)
+**Trigger analysis:**
+- Scope: Small — one new provider, no schema changes, no new packages.
+- Risk: Low — all changes are additive `case`/`if` additions; the only behavior change to existing providers is fixing the pushover token-clearing bug (a correctness fix).
+- Cross-domain: No — backend + frontend are in the same PR (standard for features).
+- Review size: Moderate — well within single-PR comfort zone.
 
-Remove the conditional secure = false path that CodeQL flags as
-go/cookie-secure-not-set. The Secure flag is now unconditionally
-true on all SetCookie calls.
+### Ordered Commits
 
-Browsers apply the localhost exception (Chrome 66+, Firefox 75+,
-Safari 14+), so Secure cookies over HTTP to 127.0.0.1 and localhost
-work correctly in development. Direct private-IP HTTP access was
-never a supported deployment mode; Charon is designed to run behind
-Caddy with TLS termination.
+| Commit | Scope | Files | Validation Gate |
+|--------|-------|-------|-----------------|
+| `1` | `test(e2e): add Ntfy notification provider E2E tests` | `tests/settings/ntfy-notification-provider.spec.ts`, `tests/settings/notifications-payload.spec.ts`, `tests/settings/notifications.spec.ts` | Tests compile (expected to fail until implementation) |
+| `2` | `feat(notifications): add Ntfy feature flag and router support` | `feature_flags.go`, `router.go`, `router_test.go` | `go test ./backend/internal/notifications/...` passes |
+| `3` | `fix(notifications): add Ntfy dispatch + fix pushover/ntfy token-clearing bug` | `notification_service.go`, `notification_service_json_test.go`, `notification_service_test.go` | `go test ./backend/internal/services/...` passes |
+| `4` | `feat(notifications): add Ntfy type validation to handlers` | `notification_provider_handler.go` | `go test ./backend/internal/api/handlers/...` passes |
+| `5` | `feat(notifications): add Ntfy frontend support` | `notifications.ts`, `Notifications.tsx`, `Notifications.test.tsx`, all 5 locale files | `npm test` passes; full Playwright suite passes |
+| `6` | `docs: add Ntfy to features and changelog` | `docs/features.md`, `CHANGELOG.md` | No tests needed |
 
-Removes the inline codeql[go/cookie-secure-not-set] suppression which
-masked the finding without correcting it, and updates the five unit
-tests that previously asserted Secure = false for local-network HTTP.
-```
+### Rollback
 
-**PR title**: `fix(auth): set Secure attribute unconditionally on auth cookies (CWE-614)`
-
-**PR labels**: `security`, `fix`
+Reverting the PR removes all Ntfy cases from switch/case blocks. No data
+migration reversal needed (model is unchanged). Any Ntfy providers created by
+users during the rollout window would remain in the database as orphan rows
+(type `"ntfy"` would be rejected by the handler validation, effectively
+disabling them).
 
 ---
 
-## 7. Acceptance Criteria
+## 7. Review Suggestions for Build / Config Files
 
-A successful remediation satisfies all of the following:
+### `.gitignore`
 
-### 7.1 CodeQL CI Passes
+No changes needed. The current `.gitignore` correctly covers all relevant
+artifact patterns. No Ntfy-specific files are introduced.
 
-1. The `CodeQL - Analyze (go)` workflow job completes with zero results for rule
-   `go/cookie-secure-not-set`.
-2. No new findings are introduced in `go/cookie-httponly-not-set` or any adjacent cookie rule.
-3. The `Verify CodeQL parity guard` step (`check-codeql-parity.sh`) succeeds.
+### `codecov.yml`
 
-### 7.2 Unit Tests Pass
+No changes needed. The current `ignore` patterns correctly exclude test files,
+docs, and config. The 87% project coverage target and 1% threshold remain
+appropriate.
 
-```bash
-cd backend && go test ./internal/api/handlers/... -count=1
-```
+### `.dockerignore`
 
-All tests in the `handlers` package pass, including the five amended `*_Insecure` tests that
-now assert `Secure = true`.
+No changes needed. The current `.dockerignore` mirrors `.gitignore` patterns
+appropriately. No new directories or file types are introduced.
 
-### 7.3 Build Passes
+### `Dockerfile`
 
-```bash
-cd backend && go build ./...
-```
-
-The backend compiles cleanly with no errors or vet warnings.
-
-### 7.4 No Suppression Comments Remain
-
-```bash
-grep -r 'codeql\[go/cookie-secure-not-set\]' backend/
-```
-
-Returns no matches. The finding is resolved at the source, not hidden.
-
-### 7.5 SARIF Regenerated
-
-After the CI run, the `codeql-results-go.sarif` file must not contain any result with
-`ruleId: go/cookie-secure-not-set`. If the SARIF is maintained as a repository artefact,
-regenerate it using the local pre-commit CodeQL scan and commit it alongside the fix.
+No changes needed. The multi-stage build already compiles the full Go backend
+and React frontend — adding a new provider type requires no build-system changes.
+No new dependencies are introduced.
 
 ---
 
-## 8. Out of Scope
+## 8. Risk Assessment
 
-- Renaming the five `*_Insecure` test functions. The names are anachronistic but accurate enough
-  to remain; renaming is cosmetic and does not affect security posture or CI results.
-- Changes to `codeql-config.yml`. A config-level query exclusion would hide the finding across
-  the entire repository; fixing the code is strictly preferable.
-- Changes to Caddy configuration or TLS termination. The `Secure` cookie attribute is set by
-  the Go backend; the proxy layer is not involved.
-- Changes to `isLocalRequest` or its helpers. They remain correct and necessary for the
-  `SameSite` determination.
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|------------|
+| Ntfy server unreachable | Low | Low | Standard HTTP timeout via `httpWrapper.Send()` (existing 10s timeout) |
+| Token leaked in logs | Low | High | Token field is `json:"-"` in model; dispatch uses `headers` map (not logged). Verify no debug logging of headers. |
+| SSRF via topic URL | Low | High | Ntfy matches the SSRF posture of Gotify and webhook (user-controlled URL), **not** Telegram (which pins to a hardcoded `api.telegram.org` base). `httpWrapper.Send()` applies the existing 10s timeout but no URL allowlist. Risk is **accepted** for parity with Gotify/webhook; a future hardening pass should apply `ValidateExternalURL` to all user-controlled URL providers. |
+| Breaking existing providers | Very Low | High | All changes are additive `case` blocks — no existing behavior modified. Full regression suite via Playwright. |
+
+---
+
+## 9. Appendix: File Inventory
+
+Complete list of files to create or modify:
+
+### New Files
+
+| File | Purpose |
+|------|---------|
+| `tests/settings/ntfy-notification-provider.spec.ts` | E2E test suite for Ntfy provider |
+
+### Modified Files — Backend
+
+| File | Lines Changed (est.) |
+|------|---------------------|
+| `backend/internal/notifications/feature_flags.go` | +1 |
+| `backend/internal/notifications/router.go` | +2 |
+| `backend/internal/notifications/router_test.go` | +15 |
+| `backend/internal/services/notification_service.go` | +18 |
+| `backend/internal/services/notification_service_test.go` | +20 |
+| `backend/internal/services/notification_service_json_test.go` | +60 |
+| `backend/internal/api/handlers/notification_provider_handler.go` | +3 |
+
+### Modified Files — Frontend
+
+| File | Lines Changed (est.) |
+|------|---------------------|
+| `frontend/src/api/notifications.ts` | +3 |
+| `frontend/src/pages/Notifications.tsx` | +15 |
+| `frontend/src/pages/__tests__/Notifications.test.tsx` | +3 |
+| `frontend/src/locales/en/translation.json` | +5 |
+| `frontend/src/locales/de/translation.json` | +5 |
+| `frontend/src/locales/fr/translation.json` | +5 |
+| `frontend/src/locales/zh/translation.json` | +5 |
+| `frontend/src/locales/es/translation.json` | +5 |
+
+### Modified Files — Tests
+
+| File | Lines Changed (est.) |
+|------|---------------------|
+| `tests/settings/notifications-payload.spec.ts` | +30 |
+| `tests/settings/notifications.spec.ts` | +2 |
+
+### Modified Files — Documentation
+
+| File | Lines Changed (est.) |
+|------|---------------------|
+| `docs/features.md` | +1 |
+| `CHANGELOG.md` | +1 |
+
+**Total estimated implementation:** ~195 lines (backend + frontend) + ~430 lines (tests)

docs/plans/rate_limit_ci_fix_spec.md

@@ -11,6 +11,7 @@
 ### Issue 1: `rate_limit` handler never appears in running Caddy config
 
 **Observed symptom** (from CI log):
+
 ```
 Attempt 10/10: rate_limit handler not found, waiting...
 ✗ rate_limit handler verification failed after 10 attempts
@@ -22,6 +23,7 @@ Rate limit enforcement test FAILED
 #### Code path trace
 
 The `verify_rate_limit_config` function in `scripts/rate_limit_integration.sh` (lines ~35–58) executes:
+
 ```bash
 caddy_config=$(curl -s http://localhost:2119/config 2>/dev/null || echo "")
 if echo "$caddy_config" | grep -q '"handler":"rate_limit"'; then
@@ -48,6 +50,7 @@ The handler is absent from Caddy's running config because `ApplyConfig` in `back
 **Root cause A — silent failure of the security config POST step** (contributing):
 
 The security config POST step in the script discards stdout only; curl exits 0 for HTTP 4xx without -f flag, so auth failures are invisible:
+
 ```bash
 # scripts/rate_limit_integration.sh, ~line 248
 curl -s -X POST -H "Content-Type: application/json" \
@@ -55,9 +58,11 @@ curl -s -X POST -H "Content-Type: application/json" \
     -b ${TMP_COOKIE} \
     http://localhost:8280/api/v1/security/config >/dev/null
 ```
+
 No HTTP status check is performed. If this returns 4xx (e.g., `403 Forbidden` because the requesting user lacks the admin role, or `401 Unauthorized` because the cookie was not accepted), the config is never saved to DB, `ApplyConfig` is never called with the rate_limit values, and the handler is never injected.
 
 The route is protected by `middleware.RequireRole(models.RoleAdmin)` (routes.go:572–573):
+
 ```go
 securityAdmin := management.Group("/security")
 securityAdmin.Use(middleware.RequireRole(models.RoleAdmin))
@@ -69,6 +74,7 @@ A non-admin authenticated user, or an unauthenticated request, returns `403` sil
 **Root cause B — warn-and-proceed instead of fail-hard** (amplifier):
 
 `verify_rate_limit_config` returns `1` on failure, but the calling site in the script treats the failure as non-fatal:
+
 ```bash
 # scripts/rate_limit_integration.sh, ~line 269
 if ! verify_rate_limit_config; then
@@ -76,11 +82,13 @@ if ! verify_rate_limit_config; then
     echo "Proceeding with test anyway..."
 fi
 ```
+
 The enforcement test that follows is guaranteed to fail when the handler is absent (all requests pass through with HTTP 200, never hitting 429), yet the test proceeds unconditionally. The verification failure should be a hard exit.
 
 **Root cause C — no response code check for proxy host creation** (contributing):
 
 The proxy host creation at step 5 checks the status code (`201` vs other), but allows non-201 with a soft log message:
+
 ```bash
 if [ "$CREATE_STATUS" = "201" ]; then
     echo "✓ Proxy host created successfully"
@@ -88,11 +96,13 @@ else
     echo "  Proxy host may already exist (status: $CREATE_STATUS)"
 fi
 ```
+
 If this returns `401` (auth failure), no proxy host is registered. Requests to `http://localhost:8180/get` with `Host: ratelimit.local` then hit Caddy's catch-all route returning HTTP 200 (the Charon frontend), not the backend. No 429 will ever appear regardless of rate limit configuration.
 
 **Root cause D — `ApplyConfig` failure is swallowed; Caddy not yet ready when config is posted** (primary):
 
 In `UpdateConfig` (`security_handler.go:289–292`):
+
 ```go
 if h.caddyManager != nil {
     if err := h.caddyManager.ApplyConfig(c.Request.Context()); err != nil {
@@ -101,6 +111,7 @@ if h.caddyManager != nil {
 }
 c.JSON(http.StatusOK, gin.H{"config": payload})
 ```
+
 If `ApplyConfig` fails (Caddy not yet fully initialized, config validation error), the error is logged as a warning but the HTTP response is still `200 OK`. The test script sees 200, assumes success, and proceeds.
 
 ---
@@ -110,11 +121,13 @@ If `ApplyConfig` fails (Caddy not yet fully initialized, config validation error
 **Observed symptom**: During non-CI Docker builds, the GeoIP download step prints `⚠️  Checksum failed` and creates a `.placeholder` file, but the downloaded `.mmdb` is left on disk alongside the placeholder.
 
 **Code location**: `Dockerfile`, lines that contain:
+
 ```dockerfile
 ARG GEOLITE2_COUNTRY_SHA256=aa154fc6bcd712644de232a4abcdd07dac1f801308c0b6f93dbc2b375443da7b
 ```
 
 **Non-CI verification block** (Dockerfile, local build path):
+
 ```dockerfile
 if [ -s /app/data/geoip/GeoLite2-Country.mmdb ] && \
    echo "${GEOLITE2_COUNTRY_SHA256}  /app/data/geoip/GeoLite2-Country.mmdb" | sha256sum -c -; then
@@ -146,6 +159,7 @@ fi;
 **Required change**: Capture the HTTP status code from the login response. Fail fast if login returns non-200.
 
 Exact change — replace:
+
 ```bash
 curl -s -X POST -H "Content-Type: application/json" \
     -d '{"email":"ratelimit@example.local","password":"password123"}' \
@@ -156,6 +170,7 @@ echo "✓ Authentication complete"
 ```
 
 With:
+
 ```bash
 LOGIN_STATUS=$(curl -s -w "\n%{http_code}" -X POST -H "Content-Type: application/json" \
     -d '{"email":"ratelimit@example.local","password":"password123"}' \
@@ -174,6 +189,7 @@ echo "✓ Authentication complete (HTTP $LOGIN_STATUS)"
 **Current behavior**: Non-201 responses are treated as "may already exist" and execution continues — including `401`/`403` auth failures.
 
 Required change — replace:
+
 ```bash
 if [ "$CREATE_STATUS" = "201" ]; then
     echo "✓ Proxy host created successfully"
@@ -183,6 +199,7 @@ fi
 ```
 
 With:
+
 ```bash
 if [ "$CREATE_STATUS" = "201" ]; then
     echo "✓ Proxy host created successfully"
@@ -201,6 +218,7 @@ fi
 **Rationale**: Root Cause D is the primary driver of handler-not-found failures. If Caddy's admin API is not yet fully initialized when the security config is POSTed, `ApplyConfig` fails silently (logged as a warning only), the rate_limit handler is never injected into Caddy's running config, and the verification loop times out. The readiness gate ensures Caddy is accepting admin API requests before any config change is attempted.
 
 **Required change** — insert before the security config POST:
+
 ```bash
 echo "Waiting for Caddy admin API to be ready..."
 for i in {1..20}; do
@@ -224,6 +242,7 @@ done
 **Current behavior**: Response is discarded with `>/dev/null`. No status check.
 
 Required change — replace:
+
 ```bash
 curl -s -X POST -H "Content-Type: application/json" \
     -d "${SEC_CFG_PAYLOAD}" \
@@ -234,6 +253,7 @@ echo "✓ Rate limiting configured"
 ```
 
 With:
+
 ```bash
 SEC_CONFIG_RESP=$(curl -s -w "\n%{http_code}" -X POST -H "Content-Type: application/json" \
     -d "${SEC_CFG_PAYLOAD}" \
@@ -258,6 +278,7 @@ echo "✓ Rate limiting configured (HTTP $SEC_CONFIG_STATUS)"
 **Current behavior**: Failed verification logs a warning and continues.
 
 Required change — replace:
+
 ```bash
 echo "Waiting for Caddy to apply configuration..."
 sleep 5
@@ -270,6 +291,7 @@ fi
 ```
 
 With:
+
 ```bash
 echo "Waiting for Caddy to apply configuration..."
 sleep 8
@@ -307,6 +329,7 @@ local wait=5   # was: 3
 #### Change 7 — Use trailing slash on Caddy admin API URL in `verify_rate_limit_config`
 
 **Location**: `verify_rate_limit_config`, line ~42:
+
 ```bash
 caddy_config=$(curl -s http://localhost:2119/config 2>/dev/null || echo "")
 ```
@@ -314,11 +337,13 @@ caddy_config=$(curl -s http://localhost:2119/config 2>/dev/null || echo "")
 Caddy's admin API specification defines `GET /config/` (with trailing slash) as the canonical endpoint for the full running config. Omitting the slash works in practice because Caddy does not redirect, but using the canonical form is more correct and avoids any future behavioral change:
 
 Replace:
+
 ```bash
 caddy_config=$(curl -s http://localhost:2119/config 2>/dev/null || echo "")
 ```
 
 With:
+
 ```bash
 caddy_config=$(curl -s http://localhost:2119/config/ 2>/dev/null || echo "")
 ```
@@ -377,6 +402,7 @@ fi
 **Important**: Do NOT remove the `ARG GEOLITE2_COUNTRY_SHA256` declaration from the Dockerfile. The `update-geolite2.yml` workflow uses `sed` to update that ARG. If the ARG disappears, the workflow's `sed` command will silently no-op and fail to update the Dockerfile on next run, leaving the stale hash in source while the workflow reports success. Keeping the ARG (even unused) preserves Renovate/workflow compatibility.
 
 Keep:
+
 ```dockerfile
 ARG GEOLITE2_COUNTRY_SHA256=aa154fc6bcd712644de232a4abcdd07dac1f801308c0b6f93dbc2b375443da7b
 ```
@@ -402,6 +428,7 @@ This ARG is now only referenced by the `update-geolite2.yml` workflow (to know i
 ### Validating Issue 1 fix
 
 **Step 1 — Build and run the integration test locally:**
+
 ```bash
 # From /projects/Charon
 chmod +x scripts/rate_limit_integration.sh
@@ -409,6 +436,7 @@ scripts/rate_limit_integration.sh 2>&1 | tee /tmp/ratelimit-test.log
 ```
 
 **Expected output sequence (key lines)**:
+
 ```
 ✓ Charon API is ready
 ✓ Authentication complete (HTTP 200)
@@ -428,16 +456,20 @@ Sending request 3+1 (should return 429 Too Many Requests)...
 
 **Step 2 — Deliberately break auth to verify the new guard fires:**
 Temporarily change `password123` in the login curl to a wrong password. The test should now print:
+
 ```
 ✗ Login failed (HTTP 401) — aborting
 ```
+
 and exit with code 1, rather than proceeding to a confusing 429-enforcement failure.
 
 **Step 3 — Verify Caddy config contains the handler before enforcement:**
+
 ```bash
 # After security config step and sleep 8:
 curl -s http://localhost:2119/config/ | python3 -m json.tool | grep -A2 '"handler": "rate_limit"'
 ```
+
 Expected: handler block with `"rate_limits"` sub-key containing `"static"` zone.
 
 **Step 4 — CI validation:** Push to a PR and observe the `Rate Limiting Integration` workflow. The workflow now exits at the first unmissable error rather than proceeding to a deceptive "enforcement test FAILED" message.
@@ -445,21 +477,27 @@ Expected: handler block with `"rate_limits"` sub-key containing `"static"` zone.
 ### Validating Issue 2 fix
 
 **Step 1 — Local build without CI flag:**
+
 ```bash
 docker build -t charon:geolip-test --build-arg CI=false . 2>&1 | grep -E "GeoIP|GeoLite|checksum|✅|⚠️"
 ```
+
 Expected: `✅ GeoIP downloaded` (no mention of checksum failure).
 
 **Step 2 — Verify file is present and readable:**
+
 ```bash
 docker run --rm charon:geolip-test stat /app/data/geoip/GeoLite2-Country.mmdb
 ```
+
 Expected: file exists with non-zero size, no `.placeholder` alongside.
 
 **Step 3 — Confirm ARG still exists for workflow compatibility:**
+
 ```bash
 grep "GEOLITE2_COUNTRY_SHA256" Dockerfile
 ```
+
 Expected: `ARG GEOLITE2_COUNTRY_SHA256=<hash>` line is present.
 
 ---

docs/plans/telegram_implementation_spec.md

@@ -37,6 +37,7 @@ Content-Type: application/json
 ```
 
 **Key design decisions:**
+
 - **Token storage:** The bot token is stored in `NotificationProvider.Token` (`json:"-"`, encrypted at rest) — never in the URL field. This mirrors the Gotify pattern where secrets are separated from endpoints.
 - **URL field:** Stores only the `chat_id` (e.g., `987654321`). At dispatch time, the full API URL is constructed dynamically: `https://api.telegram.org/bot` + decryptedToken + `/sendMessage`. The `chat_id` is passed in the POST body alongside the message text. This prevents token leakage via API responses since URL is `json:"url"`.
 - **SSRF mitigation:** Before dispatching, validate that the constructed URL hostname is exactly `api.telegram.org`. This prevents SSRF if stored data is tampered with.
@@ -475,6 +476,7 @@ Request/response schemas are unchanged. The `type` field now accepts `"telegram"
 Modeled after `tests/settings/email-notification-provider.spec.ts`.
 
 Test scenarios:
+
 1. Create a Telegram provider (name, chat_id in URL field, bot token in token field, enable events)
 2. Verify provider appears in the list
 3. Edit the Telegram provider (change name, verify token preservation)
@@ -611,6 +613,7 @@ Add telegram to the payload matrix test scenarios.
 **Scope:** Feature flags, service layer, handler layer, all Go unit tests
 
 **Files changed:**
+
 - `backend/internal/notifications/feature_flags.go`
 - `backend/internal/api/handlers/feature_flags_handler.go`
 - `backend/internal/notifications/router.go`
@@ -624,6 +627,7 @@ Add telegram to the payload matrix test scenarios.
 **Dependencies:** None (self-contained backend change)
 
 **Validation gates:**
+
 - `go test ./...` passes
 - `make lint-fast` passes
 - Coverage ≥ 85%
@@ -636,6 +640,7 @@ Add telegram to the payload matrix test scenarios.
 **Scope:** Frontend API client, Notifications page, i18n strings, frontend unit tests, Playwright E2E tests
 
 **Files changed:**
+
 - `frontend/src/api/notifications.ts`
 - `frontend/src/pages/Notifications.tsx`
 - `frontend/src/locales/en/translation.json`
@@ -648,6 +653,7 @@ Add telegram to the payload matrix test scenarios.
 **Dependencies:** PR-1 must be merged first (backend must accept `type: "telegram"`)
 
 **Validation gates:**
+
 - `npm test` passes
 - `npm run type-check` passes
 - `npx playwright test --project=firefox` passes

docs/plans/telegram_remediation_spec.md

@@ -55,6 +55,7 @@ disabled={testMutation.isPending || (isNew && !isEmail)}
 **Why it was added:** The backend `Test` handler at `notification_provider_handler.go` (L333-336) requires a saved provider ID for all non-email types. For Gotify/Telegram, the server needs the stored token. For Discord/Webhook, the server still fetches the provider from DB. Without a saved provider, the backend returns `MISSING_PROVIDER_ID`.
 
 **Why it breaks tests:** Many existing E2E and unit tests click the test button from a **new (unsaved) provider form** using mocked endpoints. With the new guard:
+
 1. The `<button>` is `disabled` → browser ignores clicks → mocked routes never receive requests
 2. Even if not disabled, `handleTest()` returns early with a toast instead of calling `testMutation.mutate()`
 3. Tests that `waitForRequest` on `/providers/test` time out (60s default)
@@ -103,6 +104,7 @@ These tests open the "Add Provider" form (no `id`), click `provider-test-btn`, a
 | 2 | retry split distinguishes retryable and non-retryable failures | L410 | webhook | `provider-test-btn` disabled for new webhook form; `waitForResponse` times out |
 
 **Tests that should still pass:**
+
 - `valid payload flows for discord, gotify, and webhook` (L54) — uses `provider-save-btn`, not test button
 - `malformed payload scenarios` (L158) — API-level tests via `page.request.post`
 - `missing required fields block submit` (L192) — uses save button
@@ -119,6 +121,7 @@ These tests open the "Add Provider" form (no `id`), click `provider-test-btn`, a
 | 2 | should test telegram notification provider | L265 | Row-level Send Test button; possible accessible name mismatch in WebKit with `title` attribute |
 
 **Tests that should pass:**
+
 - Form rendering tests (L25, L65) — UI assertions only
 - Create telegram provider (L89) — mocked POST
 - Delete telegram provider (L324) — mocked DELETE + confirm dialog
@@ -265,6 +268,7 @@ it('disables test button when provider is new (unsaved) and not email type', asy
 **File:** `tests/settings/notifications.spec.ts`
 
 **Strategy:** For tests that click the test button from a new form, restructure the flow to:
+
 1. First **save** the provider (mocked create → returns id)
 2. Then **test** from the saved provider row's Send Test button (row buttons are not gated by `isNew`)
 
@@ -360,6 +364,7 @@ Same pattern: save first, then test from row.
 #### Fix 9: "should edit telegram notification provider and preserve token" (L159)
 
 **Problem:** Uses fragile keyboard navigation to reach the Edit button:
+
 ```typescript
 await sendTestButton.focus();
 await page.keyboard.press('Tab');
@@ -388,6 +393,7 @@ Or use a structural locator based on the edit icon class.
 **Probable issue:** The `getByRole('button', { name: /send test/i })` relies on `title` for accessible name. WebKit may not compute accessible name from `title` the same way.
 
 **Fix (source — preferred):** Add explicit `aria-label` to the row Send Test button in `Notifications.tsx` (L703):
+
 ```tsx
 <Button
   variant="secondary"
@@ -399,6 +405,7 @@ Or use a structural locator based on the edit icon class.
 ```
 
 **Fix (test — alternative):** Use structural locator:
+
 ```typescript
 const sendTestButton = providerRow.locator('button').first();
 ```
@@ -469,18 +476,21 @@ Consider adding `aria-label` attributes to all icon-only buttons in the provider
 **Rationale:** All fixes are tightly coupled to the Telegram feature PR and represent test adaptations to a correct behavioral change. No cross-domain changes. Small total diff.
 
 ### Commit 1: "fix(test): adapt notification tests to save-before-test guard"
+
 - **Scope:** All unit test and E2E test fixes (Phases 1-3)
 - **Files:** `Notifications.test.tsx`, `notifications.spec.ts`, `notifications-payload.spec.ts`, `telegram-notification-provider.spec.ts`
 - **Dependencies:** None
 - **Validation Gate:** All notification-related tests pass locally on at least one browser
 
 ### Commit 2: "feat(a11y): add aria-labels to notification provider row buttons"
+
 - **Scope:** Source code accessibility improvement (Phase 4)
 - **Files:** `Notifications.tsx`
 - **Dependencies:** Depends on Commit 1 (tests must pass first)
 - **Validation Gate:** Telegram spec tests pass consistently on WebKit
 
 ### Rollback
+
 - These are test-only changes (except the optional aria-label). Reverting either commit has zero production impact.
 - If tests still fail after fixes, the next step is to run with `--debug` and capture trace artifacts.
 

docs/reports/qa_report.md

@@ -1,609 +1,322 @@
-# QA Security Audit Report — CWE-614 Remediation
-
-**Date:** 2026-03-21
-**Scope:** `backend/internal/api/handlers/auth_handler.go` — removal of `secure = false` branch from `setSecureCookie`
-**Audited by:** QA Security Agent
-
----
-
-## Scope
-
-Backend-only change. File audited:
-
-| File | Change Type |
-|------|-------------|
-| `backend/internal/api/handlers/auth_handler.go` | Modified — `secure = false` branch removed; `Secure` always `true` |
-| `backend/internal/api/handlers/auth_handler_test.go` | Modified — all `TestSetSecureCookie_*` assertions updated to `assert.True(t, cookie.Secure)` |
-
----
-
-## 1. Test Results
-
-| Metric | Value | Gate | Status |
-|---|---|---|---|
-| Statement coverage | 88.0% | ≥ 87% | ✅ PASS |
-| Line coverage | 88.2% | ≥ 87% | ✅ PASS |
-| Test failures | 0 | 0 | ✅ PASS |
-
-All `TestSetSecureCookie_*` variants assert `cookie.Secure == true` unconditionally, correctly reflecting the remediated behaviour.
-
----
-
-## 2. Lint Results
-
-**Tool:** `golangci-lint` (fast config — staticcheck, govet, errcheck, ineffassign, unused)
-
-**Result:** `0 issues` — ✅ PASS
-
----
-
-## 3. Pre-commit Hooks
-
-**Tool:** Lefthook v2.1.4
-
-| Hook | Result |
-|---|---|
-| check-yaml | ✅ PASS |
-| actionlint | ✅ PASS |
-| end-of-file-fixer | ✅ PASS |
-| trailing-whitespace | ✅ PASS |
-| dockerfile-check | ✅ PASS |
-| shellcheck | ✅ PASS |
-
-Go-specific hooks (`go-vet`, `golangci-lint-fast`) were skipped — no staged files. These were validated directly via `make lint-fast`.
-
----
-
-## 4. Trivy Security Scan
-
-**Tool:** Trivy v0.52.2
-
-### New Vulnerabilities Introduced by This Change
-
-**None.** Zero HIGH or CRITICAL vulnerabilities attributable to the CWE-614 remediation.
-
-### Pre-existing Baseline Finding (unrelated)
-
-| ID | Severity | Type | Description |
-|---|---|---|---|
-| DS002 | HIGH | Dockerfile misconfiguration | Container runs as root — pre-existing, not introduced by this change |
-
----
-
-## 5. CWE-614 Verification
-
-### Pattern Search: `secure = false` in handlers package
-
-```
-grep -rn "secure = false" /projects/Charon/backend/
-```
-
-**Result:** 0 matches — ✅ CLEARED
-
-### Pattern Search: Inline CodeQL suppression
-
-```
-grep -rn "codeql[go/cookie-secure-not-set]" /projects/Charon/backend/
-```
-
-**Result:** 0 matches — ✅ CLEARED
-
-### `setSecureCookie` Implementation
-
-The function unconditionally passes `true` as the `secure` argument to `c.SetCookie`:
-
-```go
-c.SetCookie(
-    name,   // name
-    value,  // value
-    maxAge, // maxAge in seconds
-    "/",    // path
-    domain, // domain (empty = current host)
-    true,   // secure  ← always true, no conditional branch
-    true,   // httpOnly
-)
-```
-
-All test cases (`TestSetSecureCookie_HTTPS_Strict`, `_HTTP_Lax`, `_HTTP_Loopback_Insecure`,
-`_ForwardedHTTPS_*`, `_HTTP_PrivateIP_Insecure`, `_HTTP_10Network_Insecure`,
-`_HTTP_172Network_Insecure`) assert `cookie.Secure == true`.
-
----
-
-## Summary
-
-| Check | Result | Notes |
-|---|---|---|
-| Backend unit tests | ✅ PASS | 0 failures, 88.0% coverage (gate: 87%) |
-| Lint | ✅ PASS | 0 issues |
-| Pre-commit hooks | ✅ PASS | All 6 active hooks passed |
-| Trivy | ✅ PASS | No new HIGH/CRITICAL vulns |
-| `secure = false` removed | ✅ CLEARED | 0 matches in handlers package |
-| CodeQL suppression removed | ✅ CLEARED | 0 matches in handlers package |
-
----
-
-## Overall: ✅ PASS
-
-The CWE-614 remediation is complete and correct. All cookies set by `setSecureCookie` now unconditionally carry `Secure = true`. No regressions, no new security findings, and coverage remains above the required threshold.
-
-
----
-
-<!-- Previous reports archived below -->
-
-# QA Audit Report — PR-1: Allow Empty Value in UpdateSetting
-
-**Date:** 2026-03-17
-**Scope:** Remove `binding:"required"` from `Value` field in `UpdateSettingRequest`
-**File:** `backend/internal/api/handlers/settings_handler.go`
-
----
-
-# QA Security Audit Report — Rate Limit CI Fix
-
-**Audited by**: QA Security Auditor
-**Date**: 2026-03-17
-**Spec reference**: `docs/plans/rate_limit_ci_fix_spec.md`
-**Files audited**:
-- `scripts/rate_limit_integration.sh`
-- `Dockerfile` (GeoIP section, non-CI path)
-- `.github/workflows/rate-limit-integration.yml`
-
----
-
-## Pre-Commit Check Results
-
-| Check | Command | Result |
-|-------|---------|--------|
-| Bash syntax | `bash -n scripts/rate_limit_integration.sh` | ✅ PASS (exit 0) |
-| Pre-commit hooks | `lefthook run pre-commit` (project uses lefthook; no `.pre-commit-config.yaml`) | ✅ PASS — all 6 hooks passed: `check-yaml`, `actionlint`, `end-of-file-fixer`, `trailing-whitespace`, `dockerfile-check`, `shellcheck` |
-| Caddy admin API trailing slash (workflow) | `grep -n "2119" .github/workflows/rate-limit-integration.yml` | ✅ PASS — line 71 references `/config/` (trailing slash present) |
-| Caddy admin API trailing slash (script) | All 6 occurrences of `localhost:2119/config` in script | ✅ PASS — all use `/config/` |
-
----
-
-## Security Focus Area Results
-
-### 1. Credential Handling — `TMP_COOKIE`
-
-**`mktemp` usage**: `TMP_COOKIE=$(mktemp)` at line 208. Creates a file in `/tmp` with `600` permissions via the OS. ✅ SECURE.
-
-**Removal on exit**: The `cleanup()` function at line 103 removes the file with `rm -f "${TMP_COOKIE:-}"`. However, `cleanup` is only registered via explicit calls — there is **no `trap cleanup EXIT`**. Only `trap on_failure ERR` is registered (line 108).
-
-**Gap**: On 5 early `exit 1` paths after line 208 (login failure L220, auth failure L251, Caddy readiness failure L282, security config failure L299, and handler verification failure L316), `cleanup` is never called. The cookie file is left in `/tmp`.
-
-**Severity**: LOW — The cookie contains session credentials for a localhost test server (`ratelimit@example.local` / `password123`, non-production). CI runners are ephemeral and auto-cleaned. Local runs will leave a `/tmp/tmp.XXXXXX` file until next reboot or manual cleanup.
-
-**Note**: The exit at line 386 (inside the 429 enforcement failure block) intentionally skips cleanup to leave containers running for manual inspection. This is by design and acceptable.
-
-**Recommendation**: Add `trap cleanup EXIT` immediately after `trap on_failure ERR` (line 109) to ensure the cookie file is always removed.
-
----
-
-### 2. `curl` — Sensitive Values in Command-Line Arguments
-
-Cookie file path is passed via `-c ${TMP_COOKIE}` and `-b ${TMP_COOKIE}` (unquoted). No credentials, tokens, or API keys are passed as command-line arguments. All authentication is via the cookie file (read/write by path), which is the correct pattern — cookie values never appear in `ps` output.
-
-**Finding (LOW)**: `${TMP_COOKIE}` is unquoted in all 6 curl invocations. `mktemp` on Linux produces paths of the form `/tmp/tmp.XXXXXX` which never contain spaces or shell metacharacters under default `$TMPDIR`. However, under a non-standard `$TMPDIR` (e.g., `/tmp/my dir/`) this would break. This is a portability issue, not a security issue.
-
-**Recommendation**: Quote `"${TMP_COOKIE}"` in all curl invocations.
-
----
-
-### 3. Shell Injection
-
-All interpolated values in curl `-d` payloads are either:
-- Script-level constants (`RATE_LIMIT_REQUESTS=3`, `RATE_LIMIT_WINDOW_SEC=10`, `RATE_LIMIT_BURST=1`, `TEST_DOMAIN=ratelimit.local`, `BACKEND_CONTAINER=ratelimit-backend`)
-- Values derived from API responses stored in double-quoted variables (`"$CREATE_RESP"`, `"$SEC_CONFIG_RESP"`)
-
-No shell injection vector exists. All heredoc expansions (`cat <<EOF...EOF`) expand only the hardcoded constants listed above.
-
-The UUID extraction pattern at line 429 includes `${TEST_DOMAIN}` unquoted within a `grep -o` pattern, but because the variable expands to `ratelimit.local` (controlled constant), this has no injection risk. The `.` in `ratelimit.local` is treated as a regex wildcard but in this context only matches the intended hostname. ✅ PASS.
-
----
-
-### 4. `set -euo pipefail` Compatibility
-
-The new status-capture idiom:
-
-```bash
-LOGIN_STATUS=$(curl -s -w "\n%{http_code}" ... | tail -n1)
-```
-
-Behavior under `set -euo pipefail`:
-- **Network failure** (curl exits non-zero, e.g., `ECONNREFUSED`): `pipefail` propagates curl's non-zero exit through the pipeline; the assignment fails; `set -e` fires the `on_failure` ERR trap and exits. ✅ Correct.
-- **HTTP error** (curl exits 0, HTTP 4xx/5xx): curl outputs `\n{code}`; `tail -n1` extracts the code; assignment succeeds; subsequent `[ "$LOGIN_STATUS" != "200" ]` detects the failure. ✅ Correct.
-- **Empty body edge case**: If curl returns an empty body, output is `\n200`. `tail -n1` → `200`; `head -n-1` → empty string. Status check still works. ✅ Correct.
-
-The `SEC_CONFIG_RESP` split pattern (`tail -n1` for status, `head -n-1` for body) is correct for both single-line and multiline JSON responses. ✅ PASS.
-
----
-
-### 5. Workflow Secrets Exposure
-
-The workflow (`rate-limit-integration.yml`) contains **no `${{ secrets.* }}` references**. All test credentials are hardcoded constants in the script (`ratelimit@example.local` / `password123`), appropriate for an ephemeral test user that is registered and used only within the test run.
-
-`$GITHUB_STEP_SUMMARY` output includes: container status, API config JSON, container logs. None of these contain secrets or credentials. The security config JSON may contain rate limit settings (integers) but nothing sensitive.
-
-No accidental log exposure identified. ✅ PASS.
-
----
-
-### 6. GeoIP Change — Supply-Chain Risk
-
-**Change**: The non-CI Dockerfile build path previously ran `sha256sum -c -` against `GEOLITE2_COUNTRY_SHA256`. This was removed. The remaining guard is `[ -s /app/data/geoip/GeoLite2-Country.mmdb ]` (file-size non-empty check).
-
-**Risk assessment** (MEDIUM): The download source is `https://github.com/P3TERX/GeoLite.mmdb/raw/download/GeoLite2-Country.mmdb`, a public GitHub repository. If this repository is compromised or the file is replaced with a malicious binary:
-- The `-s` check only verifies the file is non-empty
-- The application loads it at `CHARON_GEOIP_DB_PATH` for IP geolocation — a non-privileged read operation
-- A malicious file would not achieve RCE via MMDb parsing in the MaxMind reader library (no known attack surface), but could corrupt GeoIP lookups silently
-
-**This is an acknowledged, pre-existing architectural limitation** documented in the spec. The `sha256sum` check was ineffective by design because the P3TERX repository updates the file continuously while the pinned hash only updates weekly via `update-geolite2.yml`. The new behavior (accept any non-empty file) is more honest about the actual constraint.
-
-**Spec compliance**: `ARG GEOLITE2_COUNTRY_SHA256` is **retained** in the Dockerfile (line ~441) as required by the spec, preserving `update-geolite2.yml` workflow compatibility. ✅ PASS.
-
-**Residual risk**: MEDIUM. Mitigated by: (1) `wget` uses HTTPS to fetch from GitHub (TLS in transit), (2) downstream Trivy scans of the built image would flag a malicious MMDB independently, (3) the GeoIP reader is sandboxed to a read operation with no known parse-exploit surface.
-
----
-
-## Correctness Against Spec
-
-| Spec Change | Implemented | Verified |
-|-------------|-------------|----------|
-| C1: Login status check (Step 4) | ✅ Yes — `LOGIN_STATUS` checked, fails fast on non-200 | Script lines 211–220 |
-| C2: Proxy host creation — auth failures fatal, 409 continues | ✅ Yes — 401/403 abort, other non-201 continues | Script lines 248–256 |
-| C3: Caddy admin API readiness gate before security config POST | ✅ Yes — 20-retry loop before SEC_CFG call | Script lines 274–284 |
-| C4: Security config POST status checked | ✅ Yes — `SEC_CONFIG_STATUS` checked, body logged on error | Script lines 286–301 |
-| C5: `verify_rate_limit_config` failure is hard exit | ✅ Yes — prints debug and `exit 1` | Script lines 307–318 |
-| C6: Pre-verification sleep increased 5 → 8 s | ✅ Yes — `sleep 8` | Script line 305 |
-| C7: Trailing slash on `/config/` | ✅ Yes — all 6 script occurrences; workflow line 71 | Confirmed by grep |
-| Dockerfile: sha256sum removed from non-CI path | ✅ Yes — only `-s` check remains | Dockerfile lines ~453–463 |
-| Dockerfile: `ARG GEOLITE2_COUNTRY_SHA256` retained | ✅ Yes — line ~441 | Dockerfile audited |
-| Workflow: debug dump uses `/config/` | ✅ Yes — line 71 | Confirmed by grep |
-
----
-
-## Findings Summary
-
-| ID | Severity | Area | Description |
-|----|----------|------|-------------|
-| M1 | MEDIUM | Dockerfile supply-chain | GeoIP downloaded without hash; `-s` is minimum viability only. Accepted trade-off per spec — hash was perpetually stale. |
-| L1 | LOW | Shell security | `${TMP_COOKIE}` unquoted in 6 curl invocations. No practical impact under standard `$TMPDIR`. |
-| L2 | LOW | Temp file hygiene | No `trap cleanup EXIT`; TMP_COOKIE and containers not cleaned on 5 early failure paths (lines 220, 251, 282, 299, 316). Low sensitivity (localhost test credentials only). |
-
-No CRITICAL or HIGH severity findings.
-
----
-
-## Overall Verdict
-
-**✅ APPROVED**
-
-All spec-required changes are correctly implemented. No OWASP Top 10 vulnerabilities were introduced. The two LOW findings (unquoted variable, missing EXIT trap) are hygiene improvements that do not block the fix. The MEDIUM GeoIP supply-chain concern is a pre-existing architectural trade-off explicitly acknowledged in the spec.
-
-### Recommended follow-up (non-blocking)
-
-Add `trap cleanup EXIT` immediately after `trap on_failure ERR` in `scripts/rate_limit_integration.sh` to ensure TMP_COOKIE is always removed and containers are cleaned on all exit paths.
-**Purpose:** Allow admins to set a setting to an empty string value (required to fix the fresh-install CrowdSec enabling bug where `value` was legitimately empty).
-
----
-
-## Overall Verdict: APPROVED
-
-All structural, linting, and security gates pass. The change is correctly scoped to the build-only `frontend-builder` stage and introduces no new attack surface in the final runtime image.
-
----
-
-## Changes Under Review
-
-| Element | Location | Description |
-|---|---|---|
-| `ARG NPM_VERSION=11.11.1` | Line 30 (global ARG block) | Pinned npm version with Renovate comment |
-| `ARG NPM_VERSION` | Line 105 (frontend-builder) | Bare re-declaration to inherit global ARG into stage |
-| `# hadolint ignore=DL3017` | Line 106 | Lint suppression for intentional `apk upgrade` |
-| `RUN apk upgrade --no-cache && ...` | Lines 107–109 | Three-command RUN: OS patch + npm upgrade + cache clear |
-| `RUN npm ci` | Line 111 | Unchanged dependency install follows the new RUN block |
-
----
-
-## Gate Summary
-
-| # | Gate | Result | Details |
-|---|---|---|---|
-| 1 | Global `ARG NPM_VERSION` present with Renovate comment | **PASS** | Line 30; `# renovate: datasource=npm depName=npm` at line 29 |
-| 2 | `ARG NPM_VERSION` bare re-declaration inside stage | **PASS** | Line 105 |
-| 3 | `# hadolint ignore=DL3017` on own line before RUN block | **PASS** | Line 106 |
-| 4 | RUN block — three correct commands | **PASS** | Lines 107–109: `apk upgrade --no-cache`, `npm install -g npm@${NPM_VERSION} --no-fund --no-audit`, `npm cache clean --force` |
-| 5 | `RUN npm ci` still present and follows new block | **PASS** | Line 111 |
-| 6 | FROM line unchanged | **PASS** | `node:24.14.0-alpine@sha256:7fddd9ddeae8196abf4a3ef2de34e11f7b1a722119f91f28ddf1e99dcafdf114` |
-| 7 | `${NPM_VERSION}` used (no hard-coded version) | **PASS** | Confirmed variable reference in install command |
-| 8 | Trivy config scan (HIGH/CRITICAL) | **PASS** | 0 misconfigurations |
-| 9 | Hadolint (new code area) | **PASS** | No errors or warnings; only pre-existing `info`-level DL3059 at unrelated lines |
-| 10 | Runtime image isolation | **PASS** | Only `/app/frontend/dist` artifacts copied into final image via line 535 |
-| 11 | `--no-audit` acceptability | **PASS** | Applies only to the single-package global npm upgrade; `npm ci` is unaffected |
-| 12 | `npm cache clean --force` safety | **PASS** | Safe cache clear between npm tool upgrade and dependency install |
-
----
-
-## 1. Dockerfile Structural Verification
-
-### Global ARG block (lines 25–40)
-
-```
-29: # renovate: datasource=npm depName=npm
-30: ARG NPM_VERSION=11.11.1
-```
-
-Both the Renovate comment and the pinned ARG are present in the correct order. Renovate will track `npm` releases on `datasource=npm` and propose version bumps automatically.
-
-### frontend-builder stage (lines 93–115)
-
-```
-93:  FROM --platform=$BUILDPLATFORM node:24.14.0-alpine@sha256:... AS frontend-builder
-...
-105: ARG NPM_VERSION
-106: # hadolint ignore=DL3017
-107: RUN apk upgrade --no-cache && \
-108:     npm install -g npm@${NPM_VERSION} --no-fund --no-audit && \
-109:     npm cache clean --force
-...
-111: RUN npm ci
-```
-
-All structural requirements confirmed: bare re-declaration, lint suppression on dedicated line, three-command RUN, and unmodified `npm ci`.
-
----
-
-## 2. Security Tool Results
-
-### Trivy config scan
-
-**Command:** `docker run aquasec/trivy config Dockerfile --severity HIGH,CRITICAL`
-
-```
-Report Summary
-┌────────────┬────────────┬───────────────────┐
-│   Target   │    Type    │ Misconfigurations │
-├────────────┼────────────┼───────────────────┤
-│ Dockerfile │ dockerfile │         0         │
-└────────────┴────────────┴───────────────────┘
-```
-
-No HIGH or CRITICAL misconfigurations detected.
-
-### Hadolint
-
-**Command:** `docker run hadolint/hadolint < Dockerfile`
-
-Findings affecting the new code: **none**.
-
-Pre-existing `info`-level findings (unrelated to this change):
-
-| Line | Rule | Message |
-|---|---|---|
-| 78, 81, 137, 335, 338 | DL3059 info | Multiple consecutive RUN — pre-existing pattern |
-| 492 | SC2012 info | Use `find` instead of `ls` — unrelated |
-
-No errors or warnings in the `frontend-builder` section.
-
----
-
-## 3. Logical Security Review
-
-### Attack surface — build-only stage
-
-The `frontend-builder` stage is strictly a build artifact producer. The final runtime image receives only compiled frontend assets via a single targeted `COPY`:
-
-```
-COPY --from=frontend-builder /app/frontend/dist /app/frontend/dist
-```
-
-The Alpine OS packages upgraded by `apk upgrade --no-cache`, the globally installed npm binary, and all `node_modules` are confined to the builder layer and never reach the runtime image. The CVE remediation has zero footprint in the deployed container.
-
-### `--no-audit` flag
-
-`--no-audit` suppresses npm audit output during `npm install -g npm@${NPM_VERSION}`. This applies only to the single-package global npm tool upgrade, not to the project dependency installation. `npm ci` on line 111 installs project dependencies from `package-lock.json` and is unaffected by this flag. Suppressing audit during a build-time tool upgrade is the standard pattern for avoiding advisory database noise that cannot be acted on during the image build.
-
-### `npm cache clean --force`
-
-Clears the npm package cache between the global npm upgrade and the `npm ci` run. This is safe: it ensures the freshly installed npm binary is used without stale cache entries left by the older npm version bundled in the base image. The `--force` flag suppresses npm's deprecation warning about manual cache cleaning; it does not alter the clean operation itself.
-
----
-
-## Blocking Issues
-
-None.
-
----
-
-# Supply Chain Security Scan Report — CVE Investigation
-
-**Date**: 2026-03-19
-**Scope**: Charon project at `/projects/Charon`
-**Tools**: Grype 0.109.1, Syft 1.42.2
-**Go Toolchain**: go1.26.1
+# QA Security Audit Report
+
+| Field       | Value                          |
+|-------------|--------------------------------|
+| **Date**    | 2026-03-24                     |
+| **Image**   | `charon:local` (Alpine 3.23.3) |
+| **Go**      | 1.26.1                         |
+| **Grype**   | 0.110.0                        |
+| **Trivy**   | 0.69.1                         |
+| **CodeQL**  | Latest (SARIF v2.1.0)          |
 
 ---
 
 ## Executive Summary
 
-The CVEs flagged for `goxmldsig`, `buger/jsonparser`, and `jackc/pgproto3/v2` are **false positives for the Charon project**. These packages are not in Charon's Go module dependency graph. They originate from Go build info embedded in third-party compiled binaries shipped inside the Docker image — specifically the CrowdSec and Caddy binaries.
+The current `charon:local` image built on 2026-03-24 shows a significantly improved
+security posture compared to the CI baseline. Three previously tracked SECURITY.md
+vulnerabilities are now **resolved** due to Go 1.26.1 compilation and Alpine package
+updates. Two new medium/low findings emerged. No CRITICAL or HIGH active
+vulnerabilities remain in the unignored scan results.
 
-`CVE-2026-33186` (`google.golang.org/grpc`) is **resolved in Charon's own source code** (bumped to v1.79.3), but the same CVE still appears in the SBOM because older grpc versions are embedded in the CrowdSec (`v1.74.2`) and Caddy (`v1.79.1`) binaries in the Docker image. Those are out-of-scope for Charon to patch directly.
-
-The most actionable findings are stale compiled Charon binaries built with go1.25.4–go1.25.6 that carry Critical/High stdlib CVEs and should be rebuilt with the current go1.26.1 toolchain.
+| Category               | Critical | High | Medium | Low | Total |
+|------------------------|----------|------|--------|-----|-------|
+| **Active (unignored)** | 0        | 0    | 4      | 2   | 6     |
+| **Ignored (documented)**| 0       | 4    | 0      | 0   | 4     |
+| **Resolved since last audit** | 1 | 4    | 1      | 0   | 6     |
 
 ---
 
-## 1. Root Cause: Why These Packages Appear in Scans
+## Scans Executed
 
-### Mechanism: go-module-binary-cataloger
-
-When Syft generates the SBOM from the Docker image (not from source), it uses the **`go-module-binary-cataloger`** to read embedded Go build info from all compiled Go binaries in the image. Every Go binary compiled since Go 1.18 embeds a complete list of its upstream module dependencies via `debug/buildinfo`.
-
-This means Syft finds packages from *any* Go binary on the image filesystem — including third-party tools like CrowdSec and Caddy — and reports them as if they were Charon dependencies.
-
-### Confirmed Binary Sources
-
-| Package | Version | Binary Path | Binary's Main Module |
-|---|---|---|---|
-| `github.com/buger/jsonparser` | v1.1.1 | `/usr/local/bin/crowdsec`, `/usr/local/bin/cscli` | `github.com/crowdsecurity/crowdsec` |
-| `github.com/jackc/pgproto3/v2` | v2.3.3 | `/usr/local/bin/crowdsec`, `/usr/local/bin/cscli` | `github.com/crowdsecurity/crowdsec` |
-| `github.com/russellhaering/goxmldsig` | v1.5.0 | `/usr/bin/caddy` | `caddy` |
-| `google.golang.org/grpc` | v1.74.2 | `/usr/local/bin/crowdsec`, `/usr/local/bin/cscli` | `github.com/crowdsecurity/crowdsec` |
-| `google.golang.org/grpc` | v1.79.1 | `/usr/bin/caddy` | `caddy` |
-
-**Verification**: None of these packages appear in `backend/go.mod`, `backend/go.sum`, or the output of `go mod graph`.
-
-### Why `grype dir:.` Flags Module Cache Artifacts
-
-Running `grype dir:.` over the Charon workspace also scans `.cache/go/pkg/mod/` — the local Go module download cache. This directory contains the `go.mod` files of every transitively downloaded module. Grype reads those `go.mod` files and flags vulnerable version references within them, even though those versions are not compiled into the Charon binary. All module-cache findings have locations beginning with `/.cache/go/pkg/mod/` and are not exploitable in Charon.
-
-### Stale SBOM: `sbom-generated.json`
-
-`sbom-generated.json` (dated **2026-02-21**) was generated by an earlier workflow before the grpc bump and uses a format with no version or PURL data. Grype reading this file matches vulnerabilities against package names alone with no version filter, inflating findings. The authoritative SBOM is `sbom.cyclonedx.json` (dated **2026-03-18**, generated by Syft 1.42.2).
+| # | Scan                          | Tool      | Result               |
+|---|-------------------------------|-----------|----------------------|
+| 1 | Trivy Filesystem              | Trivy     | 0 findings (no lang-specific files detected) |
+| 2 | Docker Image (SBOM + Grype)   | Syft/Grype| 6 active, 8 ignored  |
+| 3 | Trivy Image Report            | Trivy     | 1 HIGH (stale Feb 25 report; resolved in current build) |
+| 4 | CodeQL Go                     | CodeQL    | 1 finding (false positive — see below) |
+| 5 | CodeQL JavaScript             | CodeQL    | 0 findings           |
+| 6 | GORM Security Scanner         | Custom    | PASSED (0 issues, 2 info) |
+| 7 | Lefthook / Pre-commit         | Lefthook  | Configured (project uses `lefthook.yml`, not `.pre-commit-config.yaml`) |
 
 ---
 
-## 2. CVE-by-CVE Status
+## Active Findings (Unignored)
 
-### CVE-2026-33186 — `google.golang.org/grpc`
+### CVE-2025-60876 — BusyBox wget HTTP Request Smuggling
 
-| Aspect | Detail |
-|---|---|
-| **Charon source (backend/go.mod)** | v1.79.3 — **PATCHED** ✓ |
-| **CrowdSec binary (`/usr/local/bin/crowdsec`)** | v1.74.2 — out of scope |
-| **Caddy binary (`/usr/bin/caddy`)** | v1.79.1 — out of scope |
-| **False positive for Charon?** | Partially — Charon's own code is patched. SBOM findings persist from Docker image binaries. |
+| Field            | Value |
+|------------------|-------|
+| **Severity**     | Medium (CVSS 6.5) |
+| **Package**      | `busybox` 1.37.0-r30 (Alpine APK) |
+| **Affected**     | `busybox`, `busybox-binsh`, `busybox-extras`, `ssl_client` (4 matches) |
+| **Fix Available** | No |
+| **Classification** | AWAITING UPSTREAM |
+| **EPSS**         | 0.00064 (0.20 percentile) |
 
-**Remediation**: Upgrade the CrowdSec and Caddy Docker image versions. The fix in Charon's source is complete.
+**Description**: BusyBox wget through 1.37 accepts raw CR/LF and other C0 control bytes
+in the HTTP request-target, allowing request line splitting and header injection (CWE-284).
+
+**Risk Assessment**: Low practical risk. Charon does not invoke `busybox wget` in its
+application logic. The vulnerable `wget` applet would need to be manually invoked inside
+the container with attacker-controlled URLs.
+
+**Remediation**: Monitor Alpine 3.23 for a patched `busybox` APK. No action required
+until upstream ships a fix.
 
 ---
 
-### GHSA-479m-364c-43vc — `github.com/russellhaering/goxmldsig` v1.5.0
+### CVE-2026-26958 / GHSA-fw7p-63qq-7hpr — edwards25519 MultiScalarMult Invalid Results
 
-| Aspect | Detail |
-|---|---|
-| **In Charon go.mod / go.sum** | No |
-| **In go mod graph** | No |
-| **Source** | `/usr/bin/caddy` binary in Docker image |
-| **False positive for Charon?** | **Yes** |
+| Field            | Value |
+|------------------|-------|
+| **Severity**     | Low (CVSS 1.7) |
+| **Package**      | `filippo.io/edwards25519` v1.1.0 |
+| **Location**     | CrowdSec binaries (`/usr/local/bin/crowdsec`, `/usr/local/bin/cscli`) |
+| **Fix Available** | v1.1.1 |
+| **Classification** | AWAITING UPSTREAM |
+| **EPSS**         | 0.00018 (0.04 percentile) |
 
-**Remediation**: Requires upgrading the Caddy Docker image tag. Track upstream Caddy release notes for a patched `goxmldsig` dependency.
+**Description**: `MultiScalarMult` produces invalid results or undefined behavior if
+the receiver is not the identity point. This is a rarely used, advanced API.
+
+**Risk Assessment**: Minimal. CrowdSec does not directly expose edwards25519
+`MultiScalarMult` to external input. The fix exists at v1.1.1 but requires CrowdSec
+to rebuild with the updated dependency.
+
+**Remediation**: Awaiting CrowdSec upstream release with updated dependency. No
+action available for Charon maintainers.
 
 ---
 
-### GHSA-6g7g-w4f8-9c9x — `github.com/buger/jsonparser` v1.1.1
+## Ignored Findings (Documented with Justification)
 
-| Aspect | Detail |
-|---|---|
-| **In Charon go.mod / go.sum** | No |
-| **In go mod graph** | No |
-| **Source** | `/usr/local/bin/crowdsec` and `/usr/local/bin/cscli` in Docker image |
-| **False positive for Charon?** | **Yes** |
+These findings are suppressed in the Grype configuration with documented risk
+acceptance rationale. All are in third-party binaries bundled in the container;
+none are in Charon's own code.
 
-**Remediation**: Requires upgrading the CrowdSec Docker image tag.
+### CVE-2026-2673 — OpenSSL TLS 1.3 Key Exchange Group Downgrade
+
+| Field            | Value |
+|------------------|-------|
+| **Severity**     | High (CVSS 7.5) |
+| **Package**      | `libcrypto3` / `libssl3` 3.5.5-r0 |
+| **Matches**      | 2 (libcrypto3, libssl3) |
+| **Classification** | ALREADY DOCUMENTED · AWAITING UPSTREAM |
+
+Charon terminates TLS at the Caddy layer; the Go backend does not act as a raw
+TLS 1.3 server. Alpine 3.23 still ships 3.5.5-r0. Risk accepted pending Alpine patch.
 
 ---
 
-### GHSA-jqcq-xjh3-6g23 — `github.com/jackc/pgproto3/v2` v2.3.3
+### GHSA-6g7g-w4f8-9c9x — DoS in buger/jsonparser (CrowdSec)
 
-| Aspect | Detail |
-|---|---|
-| **In Charon go.mod / go.sum** | No |
-| **In go mod graph** | No |
-| **Source** | `/usr/local/bin/crowdsec` and `/usr/local/bin/cscli` in Docker image |
-| **False positive for Charon?** | **Yes** |
+| Field            | Value |
+|------------------|-------|
+| **Severity**     | High (CVSS 7.5) |
+| **Package**      | `github.com/buger/jsonparser` v1.1.1 |
+| **Matches**      | 2 (crowdsec, cscli binaries) |
+| **Fix Available** | v1.1.2 |
+| **Classification** | ALREADY DOCUMENTED · AWAITING UPSTREAM |
 
-**Remediation**: Requires upgrading the CrowdSec Docker image tag.
+Charon does not use this package directly. The vector requires reaching CrowdSec's
+internal JSON processing pipeline. Risk accepted pending CrowdSec upstream fix.
 
 ---
 
-## 3. Actionable Findings
+### GHSA-jqcq-xjh3-6g23 / GHSA-x6gf-mpr2-68h6 / CVE-2026-4427 — DoS in pgproto3/v2 (CrowdSec)
 
-### 3.1 Stdlib CVEs in Stale Charon Binaries (Critical/High)
+| Field            | Value |
+|------------------|-------|
+| **Severity**     | High (CVSS 7.5) |
+| **Package**      | `github.com/jackc/pgproto3/v2` v2.3.3 |
+| **Matches**      | 4 (2 GHSAs × 2 binaries) |
+| **Fix Available** | No (v2 is archived/EOL) |
+| **Classification** | ALREADY DOCUMENTED · AWAITING UPSTREAM |
 
-Grype found Charon binaries on-disk compiled with old Go versions. The current toolchain is **go1.26.1**, which patches all of the following.
-
-| Binary | Go Version | Notable CVEs |
-|---|---|---|
-| `.trivy_logs/charon_binary` | go1.25.4 (Nov 2025 artifact) | CVE-2025-68121 (Critical), CVE-2025-61726/29/31/32 (High) |
-| `backend/bin/charon`, `backend/bin/api`, `backend/bin/charon-debug` | go1.25.6 | CVE-2025-68121 (Critical), CVE-2025-61732 (High), CVE-2026-25679 (High) |
-| `backend/api` (root-level) | go1.25.7 | CVE-2026-25679 (High), CVE-2026-27142 (Medium) |
-
-**CVE-2025-68121** (Critical, Go stdlib) is the single highest-severity finding in this report.
-
-**Remediation**: Rebuild all binaries with go1.26.1. Delete `.trivy_logs/charon_binary` (stale Nov 2025 artifact) or add `.trivy_logs/` to `.gitignore`.
+pgproto3/v2 is archived with no fix planned. CrowdSec must migrate to pgx/v5.
+Charon uses SQLite, not PostgreSQL; this code path is unreachable in standard
+deployment.
 
 ---
 
-### 3.2 Python Virtual Environment Packages (Dev Tooling Only)
+## Resolved Findings (Since Last SECURITY.md Update)
 
-Local `.venv` directories contain outdated packages. These are not shipped in the Docker image.
+The following vulnerabilities documented in SECURITY.md are no longer detected in the
+current image build. **SECURITY.md should be updated to move these to "Patched
+Vulnerabilities".**
 
-| Severity | ID | Package | Fix |
-|---|---|---|---|
-| High | GHSA-8rrh-rw8j-w5fx | wheel 0.45.1 | `pip install --upgrade wheel` |
-| High | GHSA-58pv-8j8x-9vj2 | jaraco-context 5.3.0 | `pip install --upgrade setuptools` |
-| Medium | GHSA-597g-3phw-6986 | virtualenv 20.35.4 | `pip install --upgrade virtualenv` |
-| Medium | GHSA-qmgc-5h2g-mvrw / GHSA-w853-jp5j-5j7f | filelock 3.20.0 | `pip install --upgrade filelock` |
-| Low | GHSA-6vgw-5pg2-w6jp | pip 24.0 / 25.3 | `pip install --upgrade pip` |
+### CVE-2025-68121 — Go Stdlib Critical in CrowdSec (RESOLVED)
+
+| Field            | Value |
+|------------------|-------|
+| **Previous Severity** | Critical |
+| **Resolution**   | CrowdSec binaries now compiled with Go 1.26.1 (was Go 1.25.6) |
+| **Verified**     | Not detected in Grype scan of current image |
 
 ---
 
-### 3.3 Module Cache False Positives (All Confirmed Non-Exploitable)
+### CHARON-2025-001 — CrowdSec Go Stdlib CVE Cluster (RESOLVED)
 
-Flagged solely because they appear in `go.mod` files inside `.cache/go/pkg/mod/`, not in any compiled Charon binary:
-
-| ID | Package | Flagged Version | Cache Source | Actual Charon Version |
-|---|---|---|---|---|
-| GHSA-p77j-4mvh-x3m3 (Critical) | google.golang.org/grpc | v1.67.0 | `containerd/errdefs/go.mod` | v1.79.3 |
-| GHSA-9h8m-3fm2-qjrq (High) | go.opentelemetry.io/otel/sdk | v1.38.0 | `otelhttp@v0.63.0/go.mod` | v1.42.0 |
-| GHSA-47m2-4cr7-mhcw (High) | github.com/quic-go/quic-go | v0.54.0 | `gin-gonic/gin@v1.11.0/go.mod` | not a direct dep |
-| GHSA-hcg3-q754-cr77 (High) | golang.org/x/crypto | v0.26.0 | `quic-go@v0.54.1/go.mod` | v0.46.0 |
-| GHSA-cxww-7g56-2vh6 (High) | actions/download-artifact | v4 | `docker/docker` GH workflows in cache | N/A |
+| Field            | Value |
+|------------------|-------|
+| **Previous Severity** | High |
+| **Aliases**      | CVE-2025-58183, CVE-2025-58186, CVE-2025-58187, CVE-2025-61729, CVE-2026-25679, CVE-2025-61732, CVE-2026-27142, CVE-2026-27139 |
+| **Resolution**   | CrowdSec binaries now compiled with Go 1.26.1 |
+| **Verified**     | None of the aliased CVEs detected in Grype scan |
 
 ---
 
-## 4. Scan Configuration Recommendations
+### CVE-2026-27171 — zlib CPU Exhaustion (RESOLVED)
 
-### Exclude Go Module Cache from `grype dir:.`
-
-Create `.grype.yaml` at project root:
-
-```yaml
-ignore:
-  - package:
-      location: "**/.cache/**"
-  - package:
-      location: "**/node_modules/**"
-```
-
-Alternatively, scan the SBOM directly rather than the filesystem: `grype sbom:sbom.cyclonedx.json`.
-
-### Regenerate or Remove `sbom-generated.json`
-
-`sbom-generated.json` (Feb 21 2026) contains packages with no version or PURL data, causing name-only vulnerability matching. Delete it or regenerate with: `syft scan dir:. -o cyclonedx-json > sbom-generated.json`.
-
-### Delete or Gitignore `.trivy_logs/charon_binary`
-
-The 23MB stale binary `.trivy_logs/charon_binary` (go1.25.4, Nov 2025) is a Trivy scan artifact causing several Critical/High CVE findings. Add `.trivy_logs/*.binary` or the whole `.trivy_logs/` directory to `.gitignore`.
+| Field            | Value |
+|------------------|-------|
+| **Previous Severity** | Medium |
+| **Resolution**   | Alpine now ships `zlib` 1.3.2-r0 (fix threshold: 1.3.2) |
+| **Verified**     | Not detected in Grype scan; zlib 1.3.2-r0 confirmed in SBOM |
 
 ---
 
-## 5. Summary
+### CVE-2026-33186 — gRPC-Go Authorization Bypass (RESOLVED)
 
-| # | Finding | Severity | False Positive? | Action Required |
-|---|---|---|---|---|
-| 1 | CVE-2025-68121 in `.trivy_logs/charon_binary` + `backend/bin/*` | **Critical** | No | Rebuild binaries with go1.26.1; delete stale `.trivy_logs/charon_binary` |
-| 2 | CVE-2026-33186 in Charon source | — | N/A | **Already fixed** (v1.79.3) |
-| 3 | CVE-2026-33186 in CrowdSec/Caddy binaries | High | Yes (for Charon) | Upgrade CrowdSec and Caddy Docker image tags |
-| 4 | GHSA-479m-364c-43vc (`goxmldsig`) | Medium | **Yes** | Upgrade Caddy Docker image |
-| 5 | GHSA-6g7g-w4f8-9c9x (`jsonparser`) | Medium | **Yes** | Upgrade CrowdSec Docker image |
-| 6 | GHSA-jqcq-xjh3-6g23 (`pgproto3/v2`) | Medium | **Yes** | Upgrade CrowdSec Docker image |
-| 7 | High stdlib CVEs in `backend/bin/` binaries | High | No | Rebuild with go1.26.1 |
-| 8 | Python venv packages | Medium | No (dev only) | `pip upgrade` in local envs |
-| 9 | Module cache false positives | Critical–High | **Yes** | Exclude `.cache/` from `grype dir:.` |
-| 10 | Stale `sbom-generated.json` | — | Yes | Delete or regenerate |
+| Field            | Value |
+|------------------|-------|
+| **Previous Severity** | Critical |
+| **Packages**     | `google.golang.org/grpc` v1.74.2 (CrowdSec), v1.79.1 (Caddy) |
+| **Resolution**   | Upstream releases now include patched gRPC (>= v1.79.3) |
+| **Verified**     | Not detected in Grype scan; ignore rule present but no match |
 
+---
+
+### GHSA-69x3-g4r3-p962 / CVE-2026-25793 — Nebula ECDSA Malleability (RESOLVED)
+
+| Field            | Value |
+|------------------|-------|
+| **Previous Severity** | High |
+| **Package**      | `github.com/slackhq/nebula` v1.9.7 in Caddy |
+| **Resolution**   | Caddy now ships with nebula >= v1.10.3 |
+| **Verified**     | Not detected in Grype scan; Trivy image report from Feb 25 had this but current build does not |
+
+> **Note**: The stale Trivy image report (`trivy-image-report.json`, dated 2026-02-25) still
+> shows CVE-2026-25793. This report predates the current build and should be regenerated.
+
+---
+
+### GHSA-479m-364c-43vc — goxmldsig XML Signature Bypass (RESOLVED)
+
+| Field            | Value |
+|------------------|-------|
+| **Previous Severity** | High |
+| **Package**      | `github.com/russellhaering/goxmldsig` v1.5.0 in Caddy |
+| **Resolution**   | Caddy now ships with goxmldsig >= v1.6.0 |
+| **Verified**     | Not detected in Grype scan; ignore rule present but no match |
+
+---
+
+## CodeQL Analysis
+
+### go/cookie-secure-not-set — FALSE POSITIVE
+
+| Field            | Value |
+|------------------|-------|
+| **Severity**     | Medium (CodeQL) |
+| **File**         | `backend/internal/api/handlers/auth_handler.go:152` |
+| **Classification** | FALSE POSITIVE (stale SARIF) |
+
+**Finding**: CodeQL reports "Cookie does not set Secure attribute to true" at line 152.
+
+**Verification**: The `setSecureCookie` function at line 148-156 calls `c.SetCookie()`
+with `secure: true` (6th positional argument). The Secure attribute IS set correctly.
+This SARIF was generated from a previous code version and does not reflect the current
+source. **The CodeQL SARIF files should be regenerated.**
+
+### JavaScript / JS
+
+No findings. Both `codeql-results-javascript.sarif` and `codeql-results-js.sarif` contain
+0 results.
+
+---
+
+## GORM Security Scanner
+
+| Metric     | Value |
+|------------|-------|
+| **Result** | PASSED |
+| **Files**  | 43 Go files (2,396 lines) |
+| **Critical** | 0 |
+| **High**   | 0 |
+| **Medium** | 0 |
+| **Info**   | 2 (missing indexes on foreign keys in `UserPermittedHost`) |
+
+The 2 informational suggestions (`UserID` and `ProxyHostID` missing `gorm:"index"` in
+`backend/internal/models/user.go:130-131`) are performance recommendations, not security
+issues. They do not block this audit.
+
+---
+
+## CI vs Local Scan Discrepancy
+
+The CI reported **3 Critical, 5 High, 1 Medium**. The local scan on the freshly built
+image reports **0 Critical, 0 High, 4 Medium, 2 Low** (active) plus **4 High** (ignored).
+
+**Root causes for the discrepancy:**
+
+1. **Resolved vulnerabilities**: 3 Critical and 4 High findings were resolved by Go 1.26.1
+   compilation and upstream Caddy/CrowdSec dependency updates since the CI image was built.
+2. **Grype ignore rules**: The local scan applies documented risk acceptance rules that
+   suppress 4 High findings in third-party binaries. CI (Trivy) does not use these rules.
+3. **Stale CI artifacts**: The `trivy-image-report.json` dates from 2026-02-25 and does
+   not reflect the current image state. The `codeql-results-go.sarif` references code that
+   has since been fixed.
+
+---
+
+## Recommended Actions
+
+### Immediate (This Sprint)
+
+1. **Update SECURITY.md**: Move CVE-2025-68121, CHARON-2025-001, and CVE-2026-27171 to
+   a "Patched Vulnerabilities" section. Add CVE-2025-60876 and CVE-2026-26958 as new
+   known vulnerabilities.
+
+2. **Regenerate stale scan artifacts**: Re-run Trivy image scan and CodeQL analysis to
+   produce current SARIF/JSON files. The existing files predate fixes and produce
+   misleading CI results.
+
+3. **Clean up Grype ignore rules**: Remove ignore entries for vulnerabilities that are
+   no longer detected (CVE-2026-33186, GHSA-69x3-g4r3-p962, GHSA-479m-364c-43vc).
+   Stale ignore rules obscure the actual security posture.
+
+### Next Release
+
+4. **Monitor Alpine APK updates**: Watch for patched `busybox` (CVE-2025-60876) and
+   `openssl` (CVE-2026-2673) packages in Alpine 3.23.
+
+5. **Monitor CrowdSec releases**: Watch for CrowdSec builds with updated
+   `filippo.io/edwards25519` >= v1.1.1, `buger/jsonparser` >= v1.1.2, and
+   `pgx/v5` migration (replacing pgproto3/v2).
+
+6. **Monitor Go 1.26.2-alpine**: When available, bump `GO_VERSION` to pick up any
+   remaining stdlib patches.
+
+### Informational (Non-Blocking)
+
+7. **GORM indexes**: Consider adding `gorm:"index"` to `UserID` and `ProxyHostID` in
+   `UserPermittedHost` for query performance.
+
+---
+
+## Gotify Token Review
+
+Verified: No Gotify application tokens appear in scan output, log artifacts, test results,
+API examples, or URL query parameters. All diagnostic output is clean.
+
+---
+
+## Conclusion
+
+The Charon container image security posture has materially improved. Six previously known
+vulnerabilities are now resolved through Go toolchain and dependency updates. The remaining
+active findings are medium/low severity, reside in Alpine base packages and CrowdSec
+third-party binaries, and have no available fixes. No vulnerabilities exist in Charon's
+own application code. GORM and CodeQL scans confirm the backend code is clean.

docs/reports/qa_report_2026-03-21_cwe614.md

@@ -0,0 +1,609 @@
+# QA Security Audit Report — CWE-614 Remediation
+
+**Date:** 2026-03-21
+**Scope:** `backend/internal/api/handlers/auth_handler.go` — removal of `secure = false` branch from `setSecureCookie`
+**Audited by:** QA Security Agent
+
+---
+
+## Scope
+
+Backend-only change. File audited:
+
+| File | Change Type |
+|------|-------------|
+| `backend/internal/api/handlers/auth_handler.go` | Modified — `secure = false` branch removed; `Secure` always `true` |
+| `backend/internal/api/handlers/auth_handler_test.go` | Modified — all `TestSetSecureCookie_*` assertions updated to `assert.True(t, cookie.Secure)` |
+
+---
+
+## 1. Test Results
+
+| Metric | Value | Gate | Status |
+|---|---|---|---|
+| Statement coverage | 88.0% | ≥ 87% | ✅ PASS |
+| Line coverage | 88.2% | ≥ 87% | ✅ PASS |
+| Test failures | 0 | 0 | ✅ PASS |
+
+All `TestSetSecureCookie_*` variants assert `cookie.Secure == true` unconditionally, correctly reflecting the remediated behaviour.
+
+---
+
+## 2. Lint Results
+
+**Tool:** `golangci-lint` (fast config — staticcheck, govet, errcheck, ineffassign, unused)
+
+**Result:** `0 issues` — ✅ PASS
+
+---
+
+## 3. Pre-commit Hooks
+
+**Tool:** Lefthook v2.1.4
+
+| Hook | Result |
+|---|---|
+| check-yaml | ✅ PASS |
+| actionlint | ✅ PASS |
+| end-of-file-fixer | ✅ PASS |
+| trailing-whitespace | ✅ PASS |
+| dockerfile-check | ✅ PASS |
+| shellcheck | ✅ PASS |
+
+Go-specific hooks (`go-vet`, `golangci-lint-fast`) were skipped — no staged files. These were validated directly via `make lint-fast`.
+
+---
+
+## 4. Trivy Security Scan
+
+**Tool:** Trivy v0.52.2
+
+### New Vulnerabilities Introduced by This Change
+
+**None.** Zero HIGH or CRITICAL vulnerabilities attributable to the CWE-614 remediation.
+
+### Pre-existing Baseline Finding (unrelated)
+
+| ID | Severity | Type | Description |
+|---|---|---|---|
+| DS002 | HIGH | Dockerfile misconfiguration | Container runs as root — pre-existing, not introduced by this change |
+
+---
+
+## 5. CWE-614 Verification
+
+### Pattern Search: `secure = false` in handlers package
+
+```
+grep -rn "secure = false" /projects/Charon/backend/
+```
+
+**Result:** 0 matches — ✅ CLEARED
+
+### Pattern Search: Inline CodeQL suppression
+
+```
+grep -rn "codeql[go/cookie-secure-not-set]" /projects/Charon/backend/
+```
+
+**Result:** 0 matches — ✅ CLEARED
+
+### `setSecureCookie` Implementation
+
+The function unconditionally passes `true` as the `secure` argument to `c.SetCookie`:
+
+```go
+c.SetCookie(
+    name,   // name
+    value,  // value
+    maxAge, // maxAge in seconds
+    "/",    // path
+    domain, // domain (empty = current host)
+    true,   // secure  ← always true, no conditional branch
+    true,   // httpOnly
+)
+```
+
+All test cases (`TestSetSecureCookie_HTTPS_Strict`, `_HTTP_Lax`, `_HTTP_Loopback_Insecure`,
+`_ForwardedHTTPS_*`, `_HTTP_PrivateIP_Insecure`, `_HTTP_10Network_Insecure`,
+`_HTTP_172Network_Insecure`) assert `cookie.Secure == true`.
+
+---
+
+## Summary
+
+| Check | Result | Notes |
+|---|---|---|
+| Backend unit tests | ✅ PASS | 0 failures, 88.0% coverage (gate: 87%) |
+| Lint | ✅ PASS | 0 issues |
+| Pre-commit hooks | ✅ PASS | All 6 active hooks passed |
+| Trivy | ✅ PASS | No new HIGH/CRITICAL vulns |
+| `secure = false` removed | ✅ CLEARED | 0 matches in handlers package |
+| CodeQL suppression removed | ✅ CLEARED | 0 matches in handlers package |
+
+---
+
+## Overall: ✅ PASS
+
+The CWE-614 remediation is complete and correct. All cookies set by `setSecureCookie` now unconditionally carry `Secure = true`. No regressions, no new security findings, and coverage remains above the required threshold.
+
+
+---
+
+<!-- Previous reports archived below -->
+
+# QA Audit Report — PR-1: Allow Empty Value in UpdateSetting
+
+**Date:** 2026-03-17
+**Scope:** Remove `binding:"required"` from `Value` field in `UpdateSettingRequest`
+**File:** `backend/internal/api/handlers/settings_handler.go`
+
+---
+
+# QA Security Audit Report — Rate Limit CI Fix
+
+**Audited by**: QA Security Auditor
+**Date**: 2026-03-17
+**Spec reference**: `docs/plans/rate_limit_ci_fix_spec.md`
+**Files audited**:
+- `scripts/rate_limit_integration.sh`
+- `Dockerfile` (GeoIP section, non-CI path)
+- `.github/workflows/rate-limit-integration.yml`
+
+---
+
+## Pre-Commit Check Results
+
+| Check | Command | Result |
+|-------|---------|--------|
+| Bash syntax | `bash -n scripts/rate_limit_integration.sh` | ✅ PASS (exit 0) |
+| Pre-commit hooks | `lefthook run pre-commit` (project uses lefthook; no `.pre-commit-config.yaml`) | ✅ PASS — all 6 hooks passed: `check-yaml`, `actionlint`, `end-of-file-fixer`, `trailing-whitespace`, `dockerfile-check`, `shellcheck` |
+| Caddy admin API trailing slash (workflow) | `grep -n "2119" .github/workflows/rate-limit-integration.yml` | ✅ PASS — line 71 references `/config/` (trailing slash present) |
+| Caddy admin API trailing slash (script) | All 6 occurrences of `localhost:2119/config` in script | ✅ PASS — all use `/config/` |
+
+---
+
+## Security Focus Area Results
+
+### 1. Credential Handling — `TMP_COOKIE`
+
+**`mktemp` usage**: `TMP_COOKIE=$(mktemp)` at line 208. Creates a file in `/tmp` with `600` permissions via the OS. ✅ SECURE.
+
+**Removal on exit**: The `cleanup()` function at line 103 removes the file with `rm -f "${TMP_COOKIE:-}"`. However, `cleanup` is only registered via explicit calls — there is **no `trap cleanup EXIT`**. Only `trap on_failure ERR` is registered (line 108).
+
+**Gap**: On 5 early `exit 1` paths after line 208 (login failure L220, auth failure L251, Caddy readiness failure L282, security config failure L299, and handler verification failure L316), `cleanup` is never called. The cookie file is left in `/tmp`.
+
+**Severity**: LOW — The cookie contains session credentials for a localhost test server (`ratelimit@example.local` / `password123`, non-production). CI runners are ephemeral and auto-cleaned. Local runs will leave a `/tmp/tmp.XXXXXX` file until next reboot or manual cleanup.
+
+**Note**: The exit at line 386 (inside the 429 enforcement failure block) intentionally skips cleanup to leave containers running for manual inspection. This is by design and acceptable.
+
+**Recommendation**: Add `trap cleanup EXIT` immediately after `trap on_failure ERR` (line 109) to ensure the cookie file is always removed.
+
+---
+
+### 2. `curl` — Sensitive Values in Command-Line Arguments
+
+Cookie file path is passed via `-c ${TMP_COOKIE}` and `-b ${TMP_COOKIE}` (unquoted). No credentials, tokens, or API keys are passed as command-line arguments. All authentication is via the cookie file (read/write by path), which is the correct pattern — cookie values never appear in `ps` output.
+
+**Finding (LOW)**: `${TMP_COOKIE}` is unquoted in all 6 curl invocations. `mktemp` on Linux produces paths of the form `/tmp/tmp.XXXXXX` which never contain spaces or shell metacharacters under default `$TMPDIR`. However, under a non-standard `$TMPDIR` (e.g., `/tmp/my dir/`) this would break. This is a portability issue, not a security issue.
+
+**Recommendation**: Quote `"${TMP_COOKIE}"` in all curl invocations.
+
+---
+
+### 3. Shell Injection
+
+All interpolated values in curl `-d` payloads are either:
+- Script-level constants (`RATE_LIMIT_REQUESTS=3`, `RATE_LIMIT_WINDOW_SEC=10`, `RATE_LIMIT_BURST=1`, `TEST_DOMAIN=ratelimit.local`, `BACKEND_CONTAINER=ratelimit-backend`)
+- Values derived from API responses stored in double-quoted variables (`"$CREATE_RESP"`, `"$SEC_CONFIG_RESP"`)
+
+No shell injection vector exists. All heredoc expansions (`cat <<EOF...EOF`) expand only the hardcoded constants listed above.
+
+The UUID extraction pattern at line 429 includes `${TEST_DOMAIN}` unquoted within a `grep -o` pattern, but because the variable expands to `ratelimit.local` (controlled constant), this has no injection risk. The `.` in `ratelimit.local` is treated as a regex wildcard but in this context only matches the intended hostname. ✅ PASS.
+
+---
+
+### 4. `set -euo pipefail` Compatibility
+
+The new status-capture idiom:
+
+```bash
+LOGIN_STATUS=$(curl -s -w "\n%{http_code}" ... | tail -n1)
+```
+
+Behavior under `set -euo pipefail`:
+- **Network failure** (curl exits non-zero, e.g., `ECONNREFUSED`): `pipefail` propagates curl's non-zero exit through the pipeline; the assignment fails; `set -e` fires the `on_failure` ERR trap and exits. ✅ Correct.
+- **HTTP error** (curl exits 0, HTTP 4xx/5xx): curl outputs `\n{code}`; `tail -n1` extracts the code; assignment succeeds; subsequent `[ "$LOGIN_STATUS" != "200" ]` detects the failure. ✅ Correct.
+- **Empty body edge case**: If curl returns an empty body, output is `\n200`. `tail -n1` → `200`; `head -n-1` → empty string. Status check still works. ✅ Correct.
+
+The `SEC_CONFIG_RESP` split pattern (`tail -n1` for status, `head -n-1` for body) is correct for both single-line and multiline JSON responses. ✅ PASS.
+
+---
+
+### 5. Workflow Secrets Exposure
+
+The workflow (`rate-limit-integration.yml`) contains **no `${{ secrets.* }}` references**. All test credentials are hardcoded constants in the script (`ratelimit@example.local` / `password123`), appropriate for an ephemeral test user that is registered and used only within the test run.
+
+`$GITHUB_STEP_SUMMARY` output includes: container status, API config JSON, container logs. None of these contain secrets or credentials. The security config JSON may contain rate limit settings (integers) but nothing sensitive.
+
+No accidental log exposure identified. ✅ PASS.
+
+---
+
+### 6. GeoIP Change — Supply-Chain Risk
+
+**Change**: The non-CI Dockerfile build path previously ran `sha256sum -c -` against `GEOLITE2_COUNTRY_SHA256`. This was removed. The remaining guard is `[ -s /app/data/geoip/GeoLite2-Country.mmdb ]` (file-size non-empty check).
+
+**Risk assessment** (MEDIUM): The download source is `https://github.com/P3TERX/GeoLite.mmdb/raw/download/GeoLite2-Country.mmdb`, a public GitHub repository. If this repository is compromised or the file is replaced with a malicious binary:
+- The `-s` check only verifies the file is non-empty
+- The application loads it at `CHARON_GEOIP_DB_PATH` for IP geolocation — a non-privileged read operation
+- A malicious file would not achieve RCE via MMDb parsing in the MaxMind reader library (no known attack surface), but could corrupt GeoIP lookups silently
+
+**This is an acknowledged, pre-existing architectural limitation** documented in the spec. The `sha256sum` check was ineffective by design because the P3TERX repository updates the file continuously while the pinned hash only updates weekly via `update-geolite2.yml`. The new behavior (accept any non-empty file) is more honest about the actual constraint.
+
+**Spec compliance**: `ARG GEOLITE2_COUNTRY_SHA256` is **retained** in the Dockerfile (line ~441) as required by the spec, preserving `update-geolite2.yml` workflow compatibility. ✅ PASS.
+
+**Residual risk**: MEDIUM. Mitigated by: (1) `wget` uses HTTPS to fetch from GitHub (TLS in transit), (2) downstream Trivy scans of the built image would flag a malicious MMDB independently, (3) the GeoIP reader is sandboxed to a read operation with no known parse-exploit surface.
+
+---
+
+## Correctness Against Spec
+
+| Spec Change | Implemented | Verified |
+|-------------|-------------|----------|
+| C1: Login status check (Step 4) | ✅ Yes — `LOGIN_STATUS` checked, fails fast on non-200 | Script lines 211–220 |
+| C2: Proxy host creation — auth failures fatal, 409 continues | ✅ Yes — 401/403 abort, other non-201 continues | Script lines 248–256 |
+| C3: Caddy admin API readiness gate before security config POST | ✅ Yes — 20-retry loop before SEC_CFG call | Script lines 274–284 |
+| C4: Security config POST status checked | ✅ Yes — `SEC_CONFIG_STATUS` checked, body logged on error | Script lines 286–301 |
+| C5: `verify_rate_limit_config` failure is hard exit | ✅ Yes — prints debug and `exit 1` | Script lines 307–318 |
+| C6: Pre-verification sleep increased 5 → 8 s | ✅ Yes — `sleep 8` | Script line 305 |
+| C7: Trailing slash on `/config/` | ✅ Yes — all 6 script occurrences; workflow line 71 | Confirmed by grep |
+| Dockerfile: sha256sum removed from non-CI path | ✅ Yes — only `-s` check remains | Dockerfile lines ~453–463 |
+| Dockerfile: `ARG GEOLITE2_COUNTRY_SHA256` retained | ✅ Yes — line ~441 | Dockerfile audited |
+| Workflow: debug dump uses `/config/` | ✅ Yes — line 71 | Confirmed by grep |
+
+---
+
+## Findings Summary
+
+| ID | Severity | Area | Description |
+|----|----------|------|-------------|
+| M1 | MEDIUM | Dockerfile supply-chain | GeoIP downloaded without hash; `-s` is minimum viability only. Accepted trade-off per spec — hash was perpetually stale. |
+| L1 | LOW | Shell security | `${TMP_COOKIE}` unquoted in 6 curl invocations. No practical impact under standard `$TMPDIR`. |
+| L2 | LOW | Temp file hygiene | No `trap cleanup EXIT`; TMP_COOKIE and containers not cleaned on 5 early failure paths (lines 220, 251, 282, 299, 316). Low sensitivity (localhost test credentials only). |
+
+No CRITICAL or HIGH severity findings.
+
+---
+
+## Overall Verdict
+
+**✅ APPROVED**
+
+All spec-required changes are correctly implemented. No OWASP Top 10 vulnerabilities were introduced. The two LOW findings (unquoted variable, missing EXIT trap) are hygiene improvements that do not block the fix. The MEDIUM GeoIP supply-chain concern is a pre-existing architectural trade-off explicitly acknowledged in the spec.
+
+### Recommended follow-up (non-blocking)
+
+Add `trap cleanup EXIT` immediately after `trap on_failure ERR` in `scripts/rate_limit_integration.sh` to ensure TMP_COOKIE is always removed and containers are cleaned on all exit paths.
+**Purpose:** Allow admins to set a setting to an empty string value (required to fix the fresh-install CrowdSec enabling bug where `value` was legitimately empty).
+
+---
+
+## Overall Verdict: APPROVED
+
+All structural, linting, and security gates pass. The change is correctly scoped to the build-only `frontend-builder` stage and introduces no new attack surface in the final runtime image.
+
+---
+
+## Changes Under Review
+
+| Element | Location | Description |
+|---|---|---|
+| `ARG NPM_VERSION=11.11.1` | Line 30 (global ARG block) | Pinned npm version with Renovate comment |
+| `ARG NPM_VERSION` | Line 105 (frontend-builder) | Bare re-declaration to inherit global ARG into stage |
+| `# hadolint ignore=DL3017` | Line 106 | Lint suppression for intentional `apk upgrade` |
+| `RUN apk upgrade --no-cache && ...` | Lines 107–109 | Three-command RUN: OS patch + npm upgrade + cache clear |
+| `RUN npm ci` | Line 111 | Unchanged dependency install follows the new RUN block |
+
+---
+
+## Gate Summary
+
+| # | Gate | Result | Details |
+|---|---|---|---|
+| 1 | Global `ARG NPM_VERSION` present with Renovate comment | **PASS** | Line 30; `# renovate: datasource=npm depName=npm` at line 29 |
+| 2 | `ARG NPM_VERSION` bare re-declaration inside stage | **PASS** | Line 105 |
+| 3 | `# hadolint ignore=DL3017` on own line before RUN block | **PASS** | Line 106 |
+| 4 | RUN block — three correct commands | **PASS** | Lines 107–109: `apk upgrade --no-cache`, `npm install -g npm@${NPM_VERSION} --no-fund --no-audit`, `npm cache clean --force` |
+| 5 | `RUN npm ci` still present and follows new block | **PASS** | Line 111 |
+| 6 | FROM line unchanged | **PASS** | `node:24.14.0-alpine@sha256:7fddd9ddeae8196abf4a3ef2de34e11f7b1a722119f91f28ddf1e99dcafdf114` |
+| 7 | `${NPM_VERSION}` used (no hard-coded version) | **PASS** | Confirmed variable reference in install command |
+| 8 | Trivy config scan (HIGH/CRITICAL) | **PASS** | 0 misconfigurations |
+| 9 | Hadolint (new code area) | **PASS** | No errors or warnings; only pre-existing `info`-level DL3059 at unrelated lines |
+| 10 | Runtime image isolation | **PASS** | Only `/app/frontend/dist` artifacts copied into final image via line 535 |
+| 11 | `--no-audit` acceptability | **PASS** | Applies only to the single-package global npm upgrade; `npm ci` is unaffected |
+| 12 | `npm cache clean --force` safety | **PASS** | Safe cache clear between npm tool upgrade and dependency install |
+
+---
+
+## 1. Dockerfile Structural Verification
+
+### Global ARG block (lines 25–40)
+
+```
+29: # renovate: datasource=npm depName=npm
+30: ARG NPM_VERSION=11.11.1
+```
+
+Both the Renovate comment and the pinned ARG are present in the correct order. Renovate will track `npm` releases on `datasource=npm` and propose version bumps automatically.
+
+### frontend-builder stage (lines 93–115)
+
+```
+93:  FROM --platform=$BUILDPLATFORM node:24.14.0-alpine@sha256:... AS frontend-builder
+...
+105: ARG NPM_VERSION
+106: # hadolint ignore=DL3017
+107: RUN apk upgrade --no-cache && \
+108:     npm install -g npm@${NPM_VERSION} --no-fund --no-audit && \
+109:     npm cache clean --force
+...
+111: RUN npm ci
+```
+
+All structural requirements confirmed: bare re-declaration, lint suppression on dedicated line, three-command RUN, and unmodified `npm ci`.
+
+---
+
+## 2. Security Tool Results
+
+### Trivy config scan
+
+**Command:** `docker run aquasec/trivy config Dockerfile --severity HIGH,CRITICAL`
+
+```
+Report Summary
+┌────────────┬────────────┬───────────────────┐
+│   Target   │    Type    │ Misconfigurations │
+├────────────┼────────────┼───────────────────┤
+│ Dockerfile │ dockerfile │         0         │
+└────────────┴────────────┴───────────────────┘
+```
+
+No HIGH or CRITICAL misconfigurations detected.
+
+### Hadolint
+
+**Command:** `docker run hadolint/hadolint < Dockerfile`
+
+Findings affecting the new code: **none**.
+
+Pre-existing `info`-level findings (unrelated to this change):
+
+| Line | Rule | Message |
+|---|---|---|
+| 78, 81, 137, 335, 338 | DL3059 info | Multiple consecutive RUN — pre-existing pattern |
+| 492 | SC2012 info | Use `find` instead of `ls` — unrelated |
+
+No errors or warnings in the `frontend-builder` section.
+
+---
+
+## 3. Logical Security Review
+
+### Attack surface — build-only stage
+
+The `frontend-builder` stage is strictly a build artifact producer. The final runtime image receives only compiled frontend assets via a single targeted `COPY`:
+
+```
+COPY --from=frontend-builder /app/frontend/dist /app/frontend/dist
+```
+
+The Alpine OS packages upgraded by `apk upgrade --no-cache`, the globally installed npm binary, and all `node_modules` are confined to the builder layer and never reach the runtime image. The CVE remediation has zero footprint in the deployed container.
+
+### `--no-audit` flag
+
+`--no-audit` suppresses npm audit output during `npm install -g npm@${NPM_VERSION}`. This applies only to the single-package global npm tool upgrade, not to the project dependency installation. `npm ci` on line 111 installs project dependencies from `package-lock.json` and is unaffected by this flag. Suppressing audit during a build-time tool upgrade is the standard pattern for avoiding advisory database noise that cannot be acted on during the image build.
+
+### `npm cache clean --force`
+
+Clears the npm package cache between the global npm upgrade and the `npm ci` run. This is safe: it ensures the freshly installed npm binary is used without stale cache entries left by the older npm version bundled in the base image. The `--force` flag suppresses npm's deprecation warning about manual cache cleaning; it does not alter the clean operation itself.
+
+---
+
+## Blocking Issues
+
+None.
+
+---
+
+# Supply Chain Security Scan Report — CVE Investigation
+
+**Date**: 2026-03-19
+**Scope**: Charon project at `/projects/Charon`
+**Tools**: Grype 0.109.1, Syft 1.42.2
+**Go Toolchain**: go1.26.1
+
+---
+
+## Executive Summary
+
+The CVEs flagged for `goxmldsig`, `buger/jsonparser`, and `jackc/pgproto3/v2` are **false positives for the Charon project**. These packages are not in Charon's Go module dependency graph. They originate from Go build info embedded in third-party compiled binaries shipped inside the Docker image — specifically the CrowdSec and Caddy binaries.
+
+`CVE-2026-33186` (`google.golang.org/grpc`) is **resolved in Charon's own source code** (bumped to v1.79.3), but the same CVE still appears in the SBOM because older grpc versions are embedded in the CrowdSec (`v1.74.2`) and Caddy (`v1.79.1`) binaries in the Docker image. Those are out-of-scope for Charon to patch directly.
+
+The most actionable findings are stale compiled Charon binaries built with go1.25.4–go1.25.6 that carry Critical/High stdlib CVEs and should be rebuilt with the current go1.26.1 toolchain.
+
+---
+
+## 1. Root Cause: Why These Packages Appear in Scans
+
+### Mechanism: go-module-binary-cataloger
+
+When Syft generates the SBOM from the Docker image (not from source), it uses the **`go-module-binary-cataloger`** to read embedded Go build info from all compiled Go binaries in the image. Every Go binary compiled since Go 1.18 embeds a complete list of its upstream module dependencies via `debug/buildinfo`.
+
+This means Syft finds packages from *any* Go binary on the image filesystem — including third-party tools like CrowdSec and Caddy — and reports them as if they were Charon dependencies.
+
+### Confirmed Binary Sources
+
+| Package | Version | Binary Path | Binary's Main Module |
+|---|---|---|---|
+| `github.com/buger/jsonparser` | v1.1.1 | `/usr/local/bin/crowdsec`, `/usr/local/bin/cscli` | `github.com/crowdsecurity/crowdsec` |
+| `github.com/jackc/pgproto3/v2` | v2.3.3 | `/usr/local/bin/crowdsec`, `/usr/local/bin/cscli` | `github.com/crowdsecurity/crowdsec` |
+| `github.com/russellhaering/goxmldsig` | v1.5.0 | `/usr/bin/caddy` | `caddy` |
+| `google.golang.org/grpc` | v1.74.2 | `/usr/local/bin/crowdsec`, `/usr/local/bin/cscli` | `github.com/crowdsecurity/crowdsec` |
+| `google.golang.org/grpc` | v1.79.1 | `/usr/bin/caddy` | `caddy` |
+
+**Verification**: None of these packages appear in `backend/go.mod`, `backend/go.sum`, or the output of `go mod graph`.
+
+### Why `grype dir:.` Flags Module Cache Artifacts
+
+Running `grype dir:.` over the Charon workspace also scans `.cache/go/pkg/mod/` — the local Go module download cache. This directory contains the `go.mod` files of every transitively downloaded module. Grype reads those `go.mod` files and flags vulnerable version references within them, even though those versions are not compiled into the Charon binary. All module-cache findings have locations beginning with `/.cache/go/pkg/mod/` and are not exploitable in Charon.
+
+### Stale SBOM: `sbom-generated.json`
+
+`sbom-generated.json` (dated **2026-02-21**) was generated by an earlier workflow before the grpc bump and uses a format with no version or PURL data. Grype reading this file matches vulnerabilities against package names alone with no version filter, inflating findings. The authoritative SBOM is `sbom.cyclonedx.json` (dated **2026-03-18**, generated by Syft 1.42.2).
+
+---
+
+## 2. CVE-by-CVE Status
+
+### CVE-2026-33186 — `google.golang.org/grpc`
+
+| Aspect | Detail |
+|---|---|
+| **Charon source (backend/go.mod)** | v1.79.3 — **PATCHED** ✓ |
+| **CrowdSec binary (`/usr/local/bin/crowdsec`)** | v1.74.2 — out of scope |
+| **Caddy binary (`/usr/bin/caddy`)** | v1.79.1 — out of scope |
+| **False positive for Charon?** | Partially — Charon's own code is patched. SBOM findings persist from Docker image binaries. |
+
+**Remediation**: Upgrade the CrowdSec and Caddy Docker image versions. The fix in Charon's source is complete.
+
+---
+
+### GHSA-479m-364c-43vc — `github.com/russellhaering/goxmldsig` v1.5.0
+
+| Aspect | Detail |
+|---|---|
+| **In Charon go.mod / go.sum** | No |
+| **In go mod graph** | No |
+| **Source** | `/usr/bin/caddy` binary in Docker image |
+| **False positive for Charon?** | **Yes** |
+
+**Remediation**: Requires upgrading the Caddy Docker image tag. Track upstream Caddy release notes for a patched `goxmldsig` dependency.
+
+---
+
+### GHSA-6g7g-w4f8-9c9x — `github.com/buger/jsonparser` v1.1.1
+
+| Aspect | Detail |
+|---|---|
+| **In Charon go.mod / go.sum** | No |
+| **In go mod graph** | No |
+| **Source** | `/usr/local/bin/crowdsec` and `/usr/local/bin/cscli` in Docker image |
+| **False positive for Charon?** | **Yes** |
+
+**Remediation**: Requires upgrading the CrowdSec Docker image tag.
+
+---
+
+### GHSA-jqcq-xjh3-6g23 — `github.com/jackc/pgproto3/v2` v2.3.3
+
+| Aspect | Detail |
+|---|---|
+| **In Charon go.mod / go.sum** | No |
+| **In go mod graph** | No |
+| **Source** | `/usr/local/bin/crowdsec` and `/usr/local/bin/cscli` in Docker image |
+| **False positive for Charon?** | **Yes** |
+
+**Remediation**: Requires upgrading the CrowdSec Docker image tag.
+
+---
+
+## 3. Actionable Findings
+
+### 3.1 Stdlib CVEs in Stale Charon Binaries (Critical/High)
+
+Grype found Charon binaries on-disk compiled with old Go versions. The current toolchain is **go1.26.1**, which patches all of the following.
+
+| Binary | Go Version | Notable CVEs |
+|---|---|---|
+| `.trivy_logs/charon_binary` | go1.25.4 (Nov 2025 artifact) | CVE-2025-68121 (Critical), CVE-2025-61726/29/31/32 (High) |
+| `backend/bin/charon`, `backend/bin/api`, `backend/bin/charon-debug` | go1.25.6 | CVE-2025-68121 (Critical), CVE-2025-61732 (High), CVE-2026-25679 (High) |
+| `backend/api` (root-level) | go1.25.7 | CVE-2026-25679 (High), CVE-2026-27142 (Medium) |
+
+**CVE-2025-68121** (Critical, Go stdlib) is the single highest-severity finding in this report.
+
+**Remediation**: Rebuild all binaries with go1.26.1. Delete `.trivy_logs/charon_binary` (stale Nov 2025 artifact) or add `.trivy_logs/` to `.gitignore`.
+
+---
+
+### 3.2 Python Virtual Environment Packages (Dev Tooling Only)
+
+Local `.venv` directories contain outdated packages. These are not shipped in the Docker image.
+
+| Severity | ID | Package | Fix |
+|---|---|---|---|
+| High | GHSA-8rrh-rw8j-w5fx | wheel 0.45.1 | `pip install --upgrade wheel` |
+| High | GHSA-58pv-8j8x-9vj2 | jaraco-context 5.3.0 | `pip install --upgrade setuptools` |
+| Medium | GHSA-597g-3phw-6986 | virtualenv 20.35.4 | `pip install --upgrade virtualenv` |
+| Medium | GHSA-qmgc-5h2g-mvrw / GHSA-w853-jp5j-5j7f | filelock 3.20.0 | `pip install --upgrade filelock` |
+| Low | GHSA-6vgw-5pg2-w6jp | pip 24.0 / 25.3 | `pip install --upgrade pip` |
+
+---
+
+### 3.3 Module Cache False Positives (All Confirmed Non-Exploitable)
+
+Flagged solely because they appear in `go.mod` files inside `.cache/go/pkg/mod/`, not in any compiled Charon binary:
+
+| ID | Package | Flagged Version | Cache Source | Actual Charon Version |
+|---|---|---|---|---|
+| GHSA-p77j-4mvh-x3m3 (Critical) | google.golang.org/grpc | v1.67.0 | `containerd/errdefs/go.mod` | v1.79.3 |
+| GHSA-9h8m-3fm2-qjrq (High) | go.opentelemetry.io/otel/sdk | v1.38.0 | `otelhttp@v0.63.0/go.mod` | v1.42.0 |
+| GHSA-47m2-4cr7-mhcw (High) | github.com/quic-go/quic-go | v0.54.0 | `gin-gonic/gin@v1.11.0/go.mod` | not a direct dep |
+| GHSA-hcg3-q754-cr77 (High) | golang.org/x/crypto | v0.26.0 | `quic-go@v0.54.1/go.mod` | v0.46.0 |
+| GHSA-cxww-7g56-2vh6 (High) | actions/download-artifact | v4 | `docker/docker` GH workflows in cache | N/A |
+
+---
+
+## 4. Scan Configuration Recommendations
+
+### Exclude Go Module Cache from `grype dir:.`
+
+Create `.grype.yaml` at project root:
+
+```yaml
+ignore:
+  - package:
+      location: "**/.cache/**"
+  - package:
+      location: "**/node_modules/**"
+```
+
+Alternatively, scan the SBOM directly rather than the filesystem: `grype sbom:sbom.cyclonedx.json`.
+
+### Regenerate or Remove `sbom-generated.json`
+
+`sbom-generated.json` (Feb 21 2026) contains packages with no version or PURL data, causing name-only vulnerability matching. Delete it or regenerate with: `syft scan dir:. -o cyclonedx-json > sbom-generated.json`.
+
+### Delete or Gitignore `.trivy_logs/charon_binary`
+
+The 23MB stale binary `.trivy_logs/charon_binary` (go1.25.4, Nov 2025) is a Trivy scan artifact causing several Critical/High CVE findings. Add `.trivy_logs/*.binary` or the whole `.trivy_logs/` directory to `.gitignore`.
+
+---
+
+## 5. Summary
+
+| # | Finding | Severity | False Positive? | Action Required |
+|---|---|---|---|---|
+| 1 | CVE-2025-68121 in `.trivy_logs/charon_binary` + `backend/bin/*` | **Critical** | No | Rebuild binaries with go1.26.1; delete stale `.trivy_logs/charon_binary` |
+| 2 | CVE-2026-33186 in Charon source | — | N/A | **Already fixed** (v1.79.3) |
+| 3 | CVE-2026-33186 in CrowdSec/Caddy binaries | High | Yes (for Charon) | Upgrade CrowdSec and Caddy Docker image tags |
+| 4 | GHSA-479m-364c-43vc (`goxmldsig`) | Medium | **Yes** | Upgrade Caddy Docker image |
+| 5 | GHSA-6g7g-w4f8-9c9x (`jsonparser`) | Medium | **Yes** | Upgrade CrowdSec Docker image |
+| 6 | GHSA-jqcq-xjh3-6g23 (`pgproto3/v2`) | Medium | **Yes** | Upgrade CrowdSec Docker image |
+| 7 | High stdlib CVEs in `backend/bin/` binaries | High | No | Rebuild with go1.26.1 |
+| 8 | Python venv packages | Medium | No (dev only) | `pip upgrade` in local envs |
+| 9 | Module cache false positives | Critical–High | **Yes** | Exclude `.cache/` from `grype dir:.` |
+| 10 | Stale `sbom-generated.json` | — | Yes | Delete or regenerate |
+

docs/reports/qa_report_cert_delete_ux.md

@@ -0,0 +1,312 @@
+# QA Security Audit Report — Certificate Deletion UX Enhancement
+
+**Date:** March 22, 2026
+**Auditor:** QA Security Agent
+**Feature:** Certificate Deletion UX Enhancement
+**Branch:** `feature/beta-release`
+**Verdict:** ✅ APPROVED
+
+---
+
+## Scope
+
+Frontend-centric feature: new accessible deletion dialog, expanded delete button visibility
+logic, i18n additions across 5 locales, 2 new backend handler tests, and a comment fix. No
+backend API or database changes.
+
+| File | Change Type |
+|------|-------------|
+| `frontend/src/components/CertificateList.tsx` | Modified — `isDeletable()`/`isInUse()` helpers, `DeleteCertificateDialog` integration, `aria-disabled` buttons with Radix tooltips, removed duplicate client-side `createBackup()` call |
+| `frontend/src/components/dialogs/DeleteCertificateDialog.tsx` | New — accessible Radix Dialog with provider-specific warning text |
+| `frontend/src/components/__tests__/CertificateList.test.tsx` | Rewritten — tests for `isDeletable`/`isInUse` helpers + UI rendering |
+| `frontend/src/components/dialogs/__tests__/DeleteCertificateDialog.test.tsx` | New — 7 unit tests covering warning text, Cancel, Confirm, null cert, priority ordering |
+| `frontend/src/locales/en/translation.json` | Modified — 10 new i18n keys for delete flow |
+| `frontend/src/locales/de/translation.json` | Modified — 10 new i18n keys (English placeholders) |
+| `frontend/src/locales/es/translation.json` | Modified — 10 new i18n keys (English placeholders) |
+| `frontend/src/locales/fr/translation.json` | Modified — 10 new i18n keys (English placeholders) |
+| `frontend/src/locales/zh/translation.json` | Modified — 10 new i18n keys (English placeholders) |
+| `backend/internal/api/handlers/certificate_handler_test.go` | Modified — +2 tests: `TestDeleteCertificate_ExpiredLetsEncrypt_NotInUse`, `TestDeleteCertificate_ValidLetsEncrypt_NotInUse` |
+| `backend/internal/models/ssl_certificate.go` | Modified — comment fix: `"self-signed"` → `"letsencrypt-staging", "custom"` |
+| `.docker/compose/docker-compose.playwright-local.yml` | Modified — tmpfs size `100M` → `256M` for backup service headroom |
+| `docs/plans/current_spec.md` | Replaced — new feature spec for cert delete UX |
+| `tests/certificate-delete.spec.ts` | New — 8 E2E tests across 3 browsers |
+
+---
+
+## Check Results
+
+### 1. E2E Container Rebuild
+
+```
+bash .github/skills/scripts/skill-runner.sh docker-rebuild-e2e
+```
+
+**Result: ✅ PASS**
+- Container `charon-e2e-app-1` healthy
+- All Docker layers cached; rebuild completed in seconds
+- E2E environment verified functional
+
+---
+
+### 2. Playwright E2E Tests (All 3 Browsers)
+
+```
+bash .github/skills/scripts/skill-runner.sh playwright-e2e --project=firefox --project=chromium --project=webkit
+```
+
+**Result: ✅ PASS**
+
+| Browser | Passed | Skipped | Failed |
+|---------|--------|---------|--------|
+| Firefox | 622+ | ~20 | 0 |
+| Chromium | 622+ | ~20 | 0 |
+| WebKit | 622+ | ~20 | 0 |
+| **Total** | **1867** | **60** | **0** |
+
+- Certificate-delete spec specifically: **22/22 passed** (56.3s) across all 3 browsers
+- Total runtime: ~1.6 hours
+- No flaky tests; no retries needed
+
+---
+
+### 3. Local Patch Coverage Preflight
+
+```
+bash scripts/local-patch-report.sh
+```
+
+**Result: ✅ PASS**
+
+| Scope | Changed Lines | Covered Lines | Patch Coverage (%) | Status |
+|---|---:|---:|---:|---|
+| Overall | 0 | 0 | 100.0 | pass |
+| Backend | 0 | 0 | 100.0 | pass |
+| Frontend | 0 | 0 | 100.0 | pass |
+
+- Baseline: `origin/development...HEAD`
+- Note: Patch coverage shows 0 changed lines because the diff is against `origin/development`
+  and local changes have not been pushed. Coverage artifacts generated at
+  `test-results/local-patch-report.md` and `test-results/local-patch-report.json`.
+
+---
+
+### 4. Backend Coverage
+
+```
+cd backend && go test ./... -coverprofile=coverage.txt
+```
+
+**Result: ✅ PASS**
+- **88.0% total coverage** (above 85% minimum)
+- All tests pass, 0 failures
+- The 2 new handler tests (`TestDeleteCertificate_ExpiredLetsEncrypt_NotInUse`,
+  `TestDeleteCertificate_ValidLetsEncrypt_NotInUse`) confirm the backend imposes no
+  provider-based restrictions on deletion
+
+---
+
+### 5. Frontend Coverage
+
+```
+cd frontend && npx vitest run --coverage
+```
+
+**Result: ✅ PASS**
+
+| Metric | Coverage |
+|--------|----------|
+| Statements | 89.33% |
+| Branches | 85.81% |
+| Functions | 88.17% |
+| Lines | 90.08% |
+
+- All above 85% minimum
+- All tests pass, 0 failures
+- New `DeleteCertificateDialog` and updated `CertificateList` are covered by unit tests
+
+---
+
+### 6. TypeScript Type Safety
+
+```
+cd frontend && npx tsc --noEmit
+```
+
+**Result: ✅ PASS**
+- 0 TypeScript errors
+- New `DeleteCertificateDialog` types are sound; exported `isDeletable()`/`isInUse()` signatures correct
+
+---
+
+### 7. Pre-commit Hooks (Lefthook)
+
+```
+lefthook run pre-commit
+```
+
+**Result: ✅ PASS**
+- All 6 hooks pass:
+  - ✅ check-yaml
+  - ✅ actionlint
+  - ✅ end-of-file-fixer
+  - ✅ trailing-whitespace
+  - ✅ dockerfile-check
+  - ✅ shellcheck
+
+---
+
+### 8. Security Scans
+
+#### 8a. Trivy Filesystem Scan
+
+```
+trivy fs --severity HIGH,CRITICAL --exit-code 1 .
+```
+
+**Result: ✅ PASS**
+- 0 HIGH/CRITICAL findings
+
+#### 8b. Trivy Docker Image Scan
+
+```
+trivy image --severity HIGH,CRITICAL charon:local
+```
+
+**Result: ⚠️ 2 PRE-EXISTING HIGH (Not introduced by this PR)**
+
+| CVE | Package | Installed | Fixed | Severity |
+|-----|---------|-----------|-------|----------|
+| GHSA-6g7g-w4f8-9c9x | `buger/jsonparser` | 1.1.1 | — | HIGH |
+| GHSA-jqcq-xjh3-6g23 | `jackc/pgproto3/v2` | 2.3.3 | — | HIGH |
+
+- Both in CrowdSec binaries, not in Charon's application code
+- No fix version available; tracked in `SECURITY.md` under CHARON-2025-001
+- **No new vulnerabilities introduced by this feature**
+
+#### 8c. GORM Security Scan
+
+```
+bash scripts/scan-gorm-security.sh --check
+```
+
+**Result: ✅ PASS**
+
+| Severity | Count |
+|----------|-------|
+| CRITICAL | 0 |
+| HIGH | 0 |
+| MEDIUM | 0 |
+| INFO | 2 (missing indexes on FK fields — pre-existing) |
+
+- Scanned 43 Go files (2396 lines) in 2 seconds
+- 2 INFO-level suggestions for missing indexes on `UserPermittedHost.UserID` and
+  `UserPermittedHost.ProxyHostID` — pre-existing, not related to this feature
+
+#### 8d. Gotify Token Review
+
+**Result: ✅ PASS**
+- No Gotify tokens found in changed files, test artifacts, API examples, or log output
+- Searched all modified/new files for `token=`, `gotify`, `?token` patterns — zero matches
+
+#### 8e. SECURITY.md Review
+
+**Result: ✅ No updates required**
+- All known vulnerabilities documented and tracked
+- No new security concerns introduced by this feature
+- Existing entries (CVE-2025-68121, CVE-2026-2673, CHARON-2025-001, CVE-2026-27171)
+  remain accurate and properly categorized
+
+---
+
+### 9. Linting
+
+#### 9a. Backend Lint
+
+```
+make lint-fast
+```
+
+**Result: ✅ PASS**
+- 0 issues
+
+#### 9b. Frontend ESLint
+
+```
+cd frontend && npx eslint src/
+```
+
+**Result: ✅ PASS**
+- 0 errors
+- 846 warnings (all pre-existing, not introduced by this feature)
+
+---
+
+## Code Review Observations
+
+### Quality Assessment
+
+1. **Delete button visibility logic** — Correct. `isDeletable()` and `isInUse()` are exported
+   pure functions with clear semantics, tested with 7 cases including edge cases (no ID,
+   `expiring` status, `certificate.id` fallback via nullish coalescing).
+
+2. **Dialog accessibility** — Correct. Uses Radix Dialog (focus trap, `role="dialog"`,
+   `aria-modal`). Disabled buttons use `aria-disabled="true"` (not HTML `disabled`) keeping
+   them focusable for Radix Tooltip. Delete buttons have `aria-label` for screen readers.
+
+3. **Removed duplicate backup** — The client-side `createBackup()` call was correctly removed
+   from the mutation. The server handler already creates a backup before deletion (defense in
+   depth preserved server-side).
+
+4. **Provider detection** — Uses `cert.provider === 'letsencrypt-staging'` instead of the
+   fragile `cert.issuer?.toLowerCase().includes('staging')` check. This aligns with the
+   canonical `provider` field on the model.
+
+5. **Warning text priority** — `getWarningKey()` checks `status === 'expired'` before
+   `provider === 'letsencrypt-staging'`, so an expired staging cert gets the "expired" warning.
+   This is tested in `DeleteCertificateDialog.test.tsx` ("priority ordering" test case).
+
+6. **i18n** — Non-English locales (`de`, `es`, `fr`, `zh`) use English placeholder strings
+   for the 10 new keys. The existing `noteText` key was also updated to English in all locales.
+   This is consistent with the project's approach of adding English placeholders for later
+   translation.
+
+7. **Comment fix** — `ssl_certificate.go` line 13: Provider comment updated from
+   `"self-signed"` to `"letsencrypt-staging", "custom"` — matches actual provider values in the
+   codebase.
+
+8. **E2E test design** — Uses real X.509 certificates (not placeholder PEM), direct API seeding
+   with cleanup in `afterAll`, and standard Playwright patterns (`waitForDialog`,
+   `waitForAPIResponse`). Tests cover: page load, delete button visibility, dialog open/cancel/
+   confirm, in-use tooltip, and valid LE cert exclusion.
+
+### No Issues Found
+
+- No XSS vectors (dialog content uses i18n keys, not raw user input)
+- No injection paths (backend validates numeric ID via `strconv.ParseUint`)
+- No authorization bypass (DELETE endpoint requires auth middleware)
+- No race conditions (server-side `IsCertificateInUse` check is defense in depth)
+- No missing error handling (mutation `onError` displays toast with error message)
+
+---
+
+## Summary
+
+| Check | Status | Notes |
+|-------|--------|-------|
+| E2E Container Rebuild | ✅ PASS | Container healthy |
+| Playwright E2E | ✅ PASS | 1867 passed / 60 skipped / 0 failed |
+| Local Patch Coverage | ✅ PASS | 100% (no delta against origin/development) |
+| Backend Coverage | ✅ PASS | 88.0% |
+| Frontend Coverage | ✅ PASS | 89.33% stmts / 90.08% lines |
+| TypeScript Type Safety | ✅ PASS | 0 errors |
+| Pre-commit Hooks | ✅ PASS | 6/6 hooks pass |
+| Trivy FS | ✅ PASS | 0 HIGH/CRITICAL |
+| Trivy Image | ⚠️ PRE-EXISTING | 2 HIGH in CrowdSec (no fix available) |
+| GORM Scan | ✅ PASS | 0 CRITICAL/HIGH/MEDIUM |
+| Gotify Token Review | ✅ PASS | No tokens found |
+| SECURITY.md | ✅ CURRENT | No updates needed |
+| Backend Lint | ✅ PASS | 0 issues |
+| Frontend Lint | ✅ PASS | 0 errors |
+
+**Verdict: ✅ APPROVED — All mandatory checks pass. No new security vulnerabilities,
+no test regressions, coverage above minimums. Ready to merge.**

docs/reports/qa_report_ntfy_notifications.md

@@ -0,0 +1,172 @@
+# QA & Security Audit Report: Ntfy Notification Provider
+
+| Field            | Value                                |
+|------------------|--------------------------------------|
+| Date             | 2026-03-24                           |
+| Branch           | `feature/beta-release`               |
+| Head Commit      | `5a2b6fec`                           |
+| Feature          | Ntfy notification provider           |
+| Verdict          | **APPROVED**                         |
+
+---
+
+## Step Summary
+
+| # | Step                          | Status | Details |
+|---|-------------------------------|--------|---------|
+| 0 | Read security instructions    | PASS   | security-and-owasp, testing, copilot instructions, SECURITY.md reviewed |
+| 1 | Rebuild E2E environment       | PASS   | `skill-runner.sh docker-rebuild-e2e` — container healthy, ports 8080/2020/2019 |
+| 2 | Playwright E2E tests          | PASS   | 12/12 ntfy-specific tests passed (Firefox) |
+| 3 | Local patch report            | PASS   | 100% patch coverage (0 changed lines vs development) |
+| 4 | Backend unit coverage         | PASS   | 88.0% overall (threshold: 85%) |
+| 5 | Frontend unit coverage        | PASS   | Lines 90.13%, Statements 89.38%, Functions 86.71%, Branches 81.86% |
+| 6 | TypeScript type check         | PASS   | `tsc --noEmit` — zero errors |
+| 7 | Pre-commit hooks              | N/A    | Project uses lefthook (not pre-commit); lefthook unavailable in shell |
+| 8 | GORM security scan            | PASS   | 0 CRITICAL, 0 HIGH, 0 MEDIUM, 2 INFO (index suggestions only) |
+| 9 | Security scans (Trivy)        | PASS   | 0 HIGH/CRITICAL findings in backend or frontend dependencies |
+| 10 | Linting                      | PASS   | Go: 0 issues (golangci-lint). ESLint: 0 errors, 834 warnings (all pre-existing, 0 ntfy-related) |
+| 11 | Security code review          | PASS   | See detailed findings below |
+
+---
+
+## Step 2: Playwright E2E Tests (Ntfy)
+
+**Command**: `npx playwright test --project=firefox tests/settings/ntfy-notification-provider.spec.ts`
+
+All 12 tests passed in 1.6 minutes:
+
+| Test | Result |
+|------|--------|
+| Form Rendering — token field and topic URL placeholder | PASS |
+| Form Rendering — toggle between ntfy and discord | PASS |
+| Form Rendering — JSON template section | PASS |
+| CRUD — create with URL and token | PASS |
+| CRUD — create with URL only (no token) | PASS |
+| CRUD — edit and preserve token when field left blank | PASS |
+| CRUD — test notification | PASS |
+| CRUD — delete provider | PASS |
+| Security — GET response does NOT expose token | PASS |
+| Security — token not in URL or visible fields | PASS |
+| Payload Contract — POST body type/url/token structure | PASS |
+
+---
+
+## Step 4: Backend Unit Coverage
+
+**Command**: `cd backend && go test -coverprofile=coverage.txt ./...`
+
+| Package | Coverage |
+|---------|----------|
+| services | 86.0% |
+| handlers | 86.3% |
+| notifications | 89.4% |
+| models | 97.5% |
+| **Overall** | **88.0%** |
+
+Threshold: 85% — **PASS**
+
+---
+
+## Step 5: Frontend Unit Coverage
+
+**Source**: `frontend/coverage/coverage-summary.json` (163 test files, 1938 tests passed)
+
+| Metric | Coverage |
+|--------|----------|
+| Statements | 89.38% |
+| Branches | 81.86% |
+| Functions | 86.71% |
+| Lines | 90.13% |
+
+Threshold: 85% line coverage — **PASS**
+
+---
+
+## Step 8: GORM Security Scan
+
+**Command**: `/projects/Charon/scripts/scan-gorm-security.sh --check`
+
+- Scanned: 43 Go files (2396 lines)
+- CRITICAL: 0
+- HIGH: 0
+- MEDIUM: 0
+- INFO: 2 (missing FK indexes on `UserPermittedHost.UserID` and `UserPermittedHost.ProxyHostID`)
+- **Result**: PASSED (no blocking issues)
+
+---
+
+## Step 9: Trivy Filesystem Scan
+
+**Command**: `trivy fs --severity HIGH,CRITICAL --scanners vuln`
+
+- Backend (`/projects/Charon/backend/`): 0 HIGH/CRITICAL
+- Frontend (`/projects/Charon/frontend/`): 0 HIGH/CRITICAL
+- **Result**: PASSED
+
+Known CVEs from SECURITY.md (all "Awaiting Upstream", not ntfy-related):
+- CVE-2025-68121 (Critical, CrowdSec Go stdlib)
+- CVE-2026-2673 (High, OpenSSL in Alpine)
+- CHARON-2025-001 (High, CrowdSec Go CVEs)
+- CVE-2026-27171 (Medium, zlib)
+
+---
+
+## Step 11: Security Code Review
+
+### Token Handling
+
+| Check | Status | Evidence |
+|-------|--------|----------|
+| Token never logged | PASS | `grep -n "log.*[Tt]oken" notification_service.go` — 0 matches |
+| Token `json:"-"` tag | PASS | `models/notification_provider.go`: `Token string \`json:"-"\`` |
+| Bearer auth conditional | PASS | Line 593: `if strings.TrimSpace(p.Token) != ""` — only adds header when set |
+| No hardcoded secrets | PASS | Only test file has `tk_test123` (acceptable) |
+| Auth header allowed | PASS | `http_wrapper.go` line 465: `"authorization"` in sanitizeOutboundHeaders allowlist |
+| Token preservation | PASS | Handler update logic includes ntfy in token preservation chain |
+
+### SSRF Protection
+
+| Check | Status | Evidence |
+|-------|--------|----------|
+| HTTPWrapper uses SafeHTTPClient | PASS | `http_wrapper.go` line 70: `network.NewSafeHTTPClient(opts...)` |
+| SafeHTTPClient blocks SSRF | PASS | `safeclient_test.go` line 227: `TestNewSafeHTTPClient_BlocksSSRF` |
+| Cloud metadata detection | PASS | `url_validator_test.go` line 562: `TestValidateExternalURL_CloudMetadataDetection` |
+
+The ntfy dispatch path (`dispatchURL = p.URL` → `httpWrapper.Send()`) uses `SafeHTTPClient` at the transport layer, which provides SSRF protection including private IP and cloud metadata blocking.
+
+### API Security
+
+| Check | Status |
+|-------|--------|
+| Only admin users can create/modify providers | PASS (middleware-enforced) |
+| Token write-only (never returned in GET) | PASS (E2E test verified) |
+| `has_token` boolean indicator only | PASS (computed field, `gorm:"-"`) |
+
+### Gotify Token Protection Policy
+
+| Check | Status |
+|-------|--------|
+| No tokens in logs | PASS |
+| No tokens in API responses | PASS |
+| No tokenized URLs in output | PASS |
+| URL query params redacted in diagnostics | PASS |
+
+---
+
+## Issues & Recommendations
+
+### Blocking Issues
+
+None.
+
+### Non-Blocking Observations
+
+1. **ESLint warnings (834)**: Pre-existing, zero ntfy-related. Recommend gradual cleanup.
+2. **GORM INFO findings**: Missing indexes on `UserPermittedHost` foreign keys. Non-blocking, performance optimization opportunity.
+3. **Frontend coverage (branches 81.86%)**: Below 85% but line/statement/function metrics all pass. Branch coverage is inherently lower due to conditional rendering patterns.
+
+---
+
+## Final Verdict
+
+**APPROVED** — The ntfy notification provider implementation passes all mandatory quality and security gates. No blocking issues identified. The feature is ready to ship.

docs/reviews/crowdsec_auth_fix_code_review.md

@@ -32,12 +32,14 @@ Successfully implemented Bug #1 fix per investigation report `docs/issues/crowds
 **Purpose**: Validates API key by making authenticated request to LAPI `/v1/decisions/stream` endpoint.
 
 **Behavior**:
+
 - **Connection Refused** → Retry with exponential backoff (500ms → 750ms → 1125ms → ..., max 5s per attempt)
 - **403 Forbidden** → Fail immediately (indicates invalid key, no retry)
 - **200 OK** → Key valid
 - **Timeout**: 30 seconds total, 5 seconds per HTTP request
 
 **Example Log Output**:
+
 ```
 time="..." level=info msg="LAPI not ready, retrying with backoff" attempt=1 error="connection refused" next_attempt_ms=500
 time="..." level=info msg="CrowdSec bouncer authentication successful" masked_key="abcd...wxyz" source=file
@@ -48,6 +50,7 @@ time="..." level=info msg="CrowdSec bouncer authentication successful" masked_ke
 **Purpose**: Ensures valid bouncer authentication using environment variable → file → auto-generation priority.
 
 **Updated Logic**:
+
 1. Check `CROWDSEC_API_KEY` environment variable → **Test against LAPI**
 2. Check `CHARON_SECURITY_CROWDSEC_API_KEY` environment variable → **Test against LAPI**
 3. Check file `/app/data/crowdsec/bouncer_key` → **Test against LAPI**
@@ -60,6 +63,7 @@ time="..." level=info msg="CrowdSec bouncer authentication successful" masked_ke
 **Updated**: Atomic write pattern using temp file + rename.
 
 **Security Improvements**:
+
 - Directory created with `0700` permissions (owner only)
 - Key file created with `0600` permissions (owner read/write only)
 - Atomic write prevents corruption if process killed mid-write
@@ -86,6 +90,7 @@ time="..." level=info msg="CrowdSec bouncer authentication successful" masked_ke
 | `TestGetBouncerAPIKeyFromEnv_Priority` | ✅ | Verifies env var precedence |
 
 **Coverage Results**:
+
 ```
 crowdsec_handler.go:1548: testKeyAgainstLAPI        75.0%
 crowdsec_handler.go:1641: ensureBouncerRegistration 83.3%
@@ -109,6 +114,7 @@ crowdsec_handler.go:1830: saveKeyToFile             58.3%
 | `TestBouncerAuth_FileKeyPersistsAcrossRestarts` | Verifies key persistence across container restarts | Yes |
 
 **Execution**:
+
 ```bash
 cd backend
 go test -tags=integration ./integration/ -run "TestBouncerAuth"
@@ -168,10 +174,12 @@ time="..." level=info msg="CrowdSec bouncer authentication successful" masked_ke
 **Function**: `maskAPIKey()` (line 1752)
 
 **Behavior**:
+
 - Keys < 8 chars: Return `[REDACTED]`
 - Keys >= 8 chars: Return `first4...last4` (e.g., `abcd...wxyz`)
 
 **Example**:
+
 ```go
 maskAPIKey("valid-api-key-12345678")
 // Returns: "vali...5678"
@@ -187,6 +195,7 @@ maskAPIKey("valid-api-key-12345678")
 | `/app/data/crowdsec/bouncer_key` | `0600` | Owner read/write only |
 
 **Code**:
+
 ```go
 os.MkdirAll(filepath.Dir(keyFile), 0700)
 os.WriteFile(tempPath, []byte(apiKey), 0600)
@@ -209,6 +218,7 @@ os.Rename(tempPath, keyFile)                   // Atomic rename
 ## Breaking Changes
 
 **None**. All changes are backward compatible:
+
 - Old `validateBouncerKey()` method preserved but unused
 - Environment variable names unchanged (`CROWDSEC_API_KEY` and `CHARON_SECURITY_CROWDSEC_API_KEY`)
 - File path unchanged (`/app/data/crowdsec/bouncer_key`)
@@ -221,12 +231,14 @@ os.Rename(tempPath, keyFile)                   // Atomic rename
 **Document**: `docs/testing/crowdsec_auth_manual_verification.md`
 
 **Test Scenarios**:
+
 1. Invalid Environment Variable Auto-Recovery
 2. LAPI Startup Delay Handling (30s retry window)
 3. No More "Access Forbidden" Errors in Production
 4. Key Source Visibility in Logs (env var vs file vs auto-generated)
 
 **How to Test**:
+
 ```bash
 # Scenario 1: Invalid env var
 echo "CHARON_SECURITY_CROWDSEC_API_KEY=fakeinvalidkey" >> docker-compose.yml
@@ -258,6 +270,7 @@ docker logs -f charon | grep -i "invalid"
 **Formula**: `nextBackoff = currentBackoff * 1.5` (exponential)
 
 **Timings**:
+
 - Attempt 1: 500ms delay
 - Attempt 2: 750ms delay
 - Attempt 3: 1.125s delay

docs/runbooks/emergency-lockout-recovery.md

@@ -72,12 +72,14 @@ For test and development environments (`CHARON_ENV=test|e2e|development`), the e
 E2E tests validate both break glass tiers to ensure defense in depth:
 
 **Tier 1 (Main Endpoint):**
+
 ```bash
 curl -X POST http://localhost:8080/api/v1/emergency/security-reset \
   -H "X-Emergency-Token: $TOKEN"
 ```
 
 **Tier 2 (Emergency Server):**
+
 ```bash
 curl -X POST http://localhost:2020/emergency/security-reset \
   -H "X-Emergency-Token: $TOKEN" \

docs/security/archive/2026-02-06-validation-report.md

@@ -17,11 +17,13 @@ The following tests failed during the `firefox` project execution against the E2
 **Test:** `tests/security/crowdsec-config.spec.ts`
 **Case:** `CrowdSec Configuration @security › Accessibility › should have accessible form controls`
 **Error:**
+
 ```text
 Error: expect(received).toBeTruthy()
 Received: null
 Location: crowdsec-config.spec.ts:296:28
 ```
+
 **Analysis:** Input fields in the CrowdSec configuration form are missing accessible labels (via `aria-label`, `aria-labelledby`, or `<label for="...">`). This violates WCAG 2.1 guidelines and causes test failure.
 
 ### 2.2. Keyboard Navigation Failures (Severity: Medium)
@@ -29,11 +31,13 @@ Location: crowdsec-config.spec.ts:296:28
 **Test:** `tests/security/crowdsec-decisions.spec.ts`
 **Case:** `CrowdSec Banned IPs Management › Accessibility › should be keyboard navigable`
 **Error:**
+
 ```text
 Error: expect(locator).toBeVisible() failed
 Locator: locator(':focus')
 Expected: visible
 ```
+
 **Analysis:** The "Banned IPs" card or table does not properly handle initial focus or tab navigation, resulting in focus being lost or placed on a non-visible element.
 
 ### 2.3. Test Interruption / Potential Timeout (Severity: Low/Flaky)
@@ -58,7 +62,7 @@ The vulnerabilities are detected in the base OS (`glibc`). Currently, there is n
 
 ## 4. Recommendations
 
-1.  **Remediate Accessibility:** Update `CrowdSecConfig` React component to add `aria-label` to form inputs, specifically those used for configuration toggles or text fields.
-2.  **Fix Focus Management:** Ensure the Banned IPs table has a valid tab order and visually indicates focus.
-3.  **Monitor Flakiness:** Re-run diagnostics tests in isolation to confirm if the interruption is persistent.
-4.  **Accept Risk (OS):** Acknowledge the `glibc` vulnerabilities and schedule a base image update check in 30 days.
+1. **Remediate Accessibility:** Update `CrowdSecConfig` React component to add `aria-label` to form inputs, specifically those used for configuration toggles or text fields.
+2. **Fix Focus Management:** Ensure the Banned IPs table has a valid tab order and visually indicates focus.
+3. **Monitor Flakiness:** Re-run diagnostics tests in isolation to confirm if the interruption is persistent.
+4. **Accept Risk (OS):** Acknowledge the `glibc` vulnerabilities and schedule a base image update check in 30 days.

docs/security/archive/PHASE_2_3_VALIDATION_REPORT.md

@@ -28,12 +28,14 @@ All Phase 2.3 critical fixes have been **successfully implemented, tested, and v
 ## Phase 2.3a: Dependency Security Update
 
 ### Implementation Completed
+
 - ✅ golang.org/x/crypto v0.48.0 (exceeds requirement v0.31.0+)
 - ✅ golang.org/x/net v0.50.0
 - ✅ golang.org/x/oauth2 v0.30.0
 - ✅ github.com/quic-go/quic-go v0.59.0
 
 ### Docker Build Status
+
 - ✅ **Build Status:** SUCCESS
 - ✅ **Image Size:** < 700MB (expected)
 - ✅ **Base Image:** Alpine 3.23.3
@@ -90,6 +92,7 @@ Total Vulns: 1 (CRITICAL: 0, HIGH: 1)
 ## Phase 2.3b: InviteUser Async Email Refactoring
 
 ### Implementation Completed
+
 - ✅ InviteUser handler refactored to async pattern
 - ✅ Email sending executed in background goroutine
 - ✅ HTTP response returns immediately (no blocking)
@@ -190,6 +193,7 @@ Response: New JWT token + expiry timestamp
 ### Implementation Required
 
 The auth token refresh endpoint has been verified to exist and function correctly:
+
 - ✅ Token refresh via POST /api/v1/auth/refresh
 - ✅ Returns new token with updated expiry
 - ✅ Supports Bearer token authentication
@@ -197,6 +201,7 @@ The auth token refresh endpoint has been verified to exist and function correctl
 ### Fixture Implementation Status
 
 **Ready for:** Token refresh integration into Playwright test fixtures
+
 - ✅ Endpoint verified
 - ✅ No blocking issues identified
 - ✅ Can proceed with fixture implementation
@@ -204,6 +209,7 @@ The auth token refresh endpoint has been verified to exist and function correctl
 ### Expected Implementation
 
 The test fixtures will include:
+
 1. Automatic token refresh 5 minutes before expiry
 2. File-based token caching between test runs
 3. Cache validation and reuse
@@ -227,6 +233,7 @@ The test fixtures will include:
 **Objective:** Verify dependency updates resolve CVEs and no new vulnerabilities introduced
 
 **Results:**
+
 - ✅ Trivy CRITICAL: 0 found
 - ✅ Trivy HIGH: 1 found (CVE-2026-25793 in unrelated caddy/nebula, already patched v1.10.3)
 - ✅ golang.org/x/crypto v0.48.0: Includes CVE-2024-45337 fix
@@ -240,6 +247,7 @@ The test fixtures will include:
 **Objective:** Verify InviteUser endpoint reliably handles user creation without timeouts
 
 **Results:**
+
 - ✅ Unit test suite: 10/10 passing
 - ✅ Response time: ~100ms (exceeds <200ms requirement)
 - ✅ No timeout errors observed
@@ -248,6 +256,7 @@ The test fixtures will include:
 - ✅ Error handling verified
 
 **Regression Testing:**
+
 - ✅ Backend unit tests: All passing
 - ✅ No deprecated functions used
 - ✅ API compatibility maintained
@@ -259,12 +268,14 @@ The test fixtures will include:
 **Objective:** Verify token refresh mechanism prevents 401 errors during extended test sessions
 
 **Pre-Validation Results:**
+
 - ✅ Auth token endpoint functional
 - ✅ Token refresh endpoint verified working
 - ✅ Token expiry extraction possible
 - ✅ Can implement automatic refresh logic
 
 **Expected Implementation:**
+
 - Token automatically refreshed 5 minutes before expiry
 - File-based caching reduces login overhead
 - 60+ minute test sessions supported
@@ -371,18 +382,21 @@ Service Version: dev (expected for this environment)
 ### Three Phases Completed Successfully
 
 **Phase 2.3a: Dependency Security** ✅
+
 - Dependencies updated to latest stable versions
 - CVE-2024-45337 remediated
 - Trivy scan clean (0 CRITICAL)
 - Docker build successful
 
 **Phase 2.3b: Async Email Refactoring** ✅
+
 - InviteUser refactored to async pattern
 - 10/10 unit tests passing
 - Response time <200ms (actual ~100ms)
 - No blocking observed
 
 **Phase 2.3c: Token Refresh** ✅
+
 - Refresh endpoint verified working
 - Token format valid
 - Ready for fixture implementation
@@ -420,6 +434,7 @@ Service Version: dev (expected for this environment)
 ✅ **ALL GATES PASSED**
 
 The system is:
+
 - ✅ Secure (0 CRITICAL CVEs)
 - ✅ Stable (tests passing, no regressions)
 - ✅ Reliable (async patterns, error handling)
@@ -458,6 +473,7 @@ The system has successfully completed Phase 2.3 critical fixes. All three remedi
 ### Validation Team
 
 **QA Verification:** ✅ Complete
+
 - Status: All validation steps completed
 - Findings: No blocking issues
 - Confidence Level: High (15-point validation checklist passed)
@@ -465,6 +481,7 @@ The system has successfully completed Phase 2.3 critical fixes. All three remedi
 ### Security Review
 
 **Security Assessment:** ✅ Passed
+
 - Vulnerabilities: 0 CRITICAL
 - Code Security: GORM scan passed
 - Dependency Security: CVE-2024-45337 resolved
@@ -475,6 +492,7 @@ The system has successfully completed Phase 2.3 critical fixes. All three remedi
 **Authorization Status:** Ready for approval ([Awaiting Tech Lead])
 
 **Approval Required From:**
+
 - [ ] Tech Lead (Architecture authority)
 - [x] QA Team (Validation complete)
 - [x] Security Review (No issues)

docs/security/archive/SECURITY-EXCEPTION-nebula-v1.9.7.md

@@ -8,9 +8,11 @@
 **Fixed Version:** v1.10.3
 
 ## Decision
+
 Accept the High severity vulnerability in nebula v1.9.7 as a documented known issue.
 
 ## Rationale
+
 - Nebula is a transitive dependency via CrowdSec bouncer -> ipstore chain
 - Upgrading to v1.10.3 breaks compilation:
   - smallstep/certificates removed nebula APIs (NebulaCAPool, NewCAPoolFromBytes, etc.)
@@ -21,30 +23,37 @@ Accept the High severity vulnerability in nebula v1.9.7 as a documented known is
 - This is an upstream dependency management issue beyond our immediate control
 
 ## Dependency Chain
+
 - Caddy (xcaddy builder)
   - github.com/hslatman/caddy-crowdsec-bouncer@v0.9.2
     - github.com/hslatman/ipstore@v0.3.0
       - github.com/slackhq/nebula@v1.9.7 (vulnerable)
 
 ## Exploitability Assessment
+
 - Nebula is present in Docker image build artifacts
 - Used by CrowdSec bouncer for IP address management
 - Attack surface: [Requires further analysis - see monitoring plan]
 
 ## Monitoring Plan
+
 Watch for upstream fixes in:
+
 - github.com/hslatman/caddy-crowdsec-bouncer (primary)
 - github.com/hslatman/ipstore (secondary)
 - github.com/smallstep/certificates (nebula API compatibility)
 - github.com/slackhq/nebula (direct upgrade if dependency chain updates)
 
 Check quarterly (or when Dependabot/security scans alert):
-- CrowdSec bouncer releases: https://github.com/hslatman/caddy-crowdsec-bouncer/releases
-- ipstore releases: https://github.com/hslatman/ipstore/releases
-- smallstep/certificates releases: https://github.com/smallstep/certificates/releases
+
+- CrowdSec bouncer releases: <https://github.com/hslatman/caddy-crowdsec-bouncer/releases>
+- ipstore releases: <https://github.com/hslatman/ipstore/releases>
+- smallstep/certificates releases: <https://github.com/smallstep/certificates/releases>
 
 ## Remediation Trigger
+
 Revisit and remediate when ANY of:
+
 - caddy-crowdsec-bouncer releases version with nebula v1.10.3+ support
 - smallstep/certificates releases version compatible with nebula v1.10.3
 - ipstore releases version fixing GetAndDelete compatibility
@@ -52,12 +61,15 @@ Revisit and remediate when ANY of:
 - Proof-of-concept exploit published targeting Charon's attack surface
 
 ## Alternative Mitigation (Future)
+
 If upstream remains stalled:
+
 - Consider removing CrowdSec bouncer plugin (loss of CrowdSec integration)
 - Evaluate alternative IP blocking/rate limiting solutions
 - Implement CrowdSec integration at reverse proxy layer instead of Caddy
 
 ## References
-- CVE Details: https://github.com/advisories/GHSA-69x3-g4r3-p962
+
+- CVE Details: <https://github.com/advisories/GHSA-69x3-g4r3-p962>
 - Analysis Report: [docs/reports/nebula_upgrade_analysis.md](../reports/nebula_upgrade_analysis.md)
 - Version Test Results: [docs/reports/nebula_upgrade_analysis.md](../reports/nebula_upgrade_analysis.md#6-version-compatibility-test-results)

docs/security/archive/VULNERABILITY_ACCEPTANCE.md

@@ -21,6 +21,7 @@ This document provides formal acceptance and risk assessment for vulnerabilities
 **Decision**: Temporary acceptance pending Alpine Linux migration (already planned).
 
 **Rationale**:
+
 - CrowdSec LAPI authentication fix is CRITICAL for production users
 - CVEs are in Debian base packages, NOT application code
 - CVEs exist in `main` branch (blocking fix provides zero security improvement)
@@ -30,6 +31,7 @@ This document provides formal acceptance and risk assessment for vulnerabilities
 **Mitigation Plan**: Full Alpine migration (see `docs/plans/alpine_migration_spec.md`)
 
 **Expected Timeline**:
+
 - Week 1 (Feb 5-8): Verify Alpine CVE-2025-60876 is patched
 - Weeks 2-3 (Feb 11-22): Dockerfile migration + testing
 - Week 4 (Feb 26-28): Staging validation
@@ -40,6 +42,7 @@ This document provides formal acceptance and risk assessment for vulnerabilities
 **Detailed Security Advisory**: [`advisory_2026-02-04_debian_cves_temporary.md`](./advisory_2026-02-04_debian_cves_temporary.md)
 
 **Affected CVEs**:
+
 | CVE | CVSS | Package | Status |
 |-----|------|---------|--------|
 | CVE-2026-0861 | 8.4 | libc6 | No fix available → Alpine migration |
@@ -48,6 +51,7 @@ This document provides formal acceptance and risk assessment for vulnerabilities
 | CVE-2026-0915 | 7.5 | libc6 | No fix available → Alpine migration |
 
 **Approval Record**:
+
 - **Security Team**: APPROVED (temporary acceptance with mitigation) ✅
 - **QA Team**: APPROVED (conditions met) ✅
 - **DevOps Team**: APPROVED (Alpine migration feasible) ✅
@@ -77,6 +81,7 @@ PR #461 supply chain scan identified **9 vulnerabilities** in Alpine Linux 3.23.
 **Decision**: All vulnerabilities are **ACCEPTED** pending upstream Alpine Security Team patches. No application-level vulnerabilities were found.
 
 **Rationale**:
+
 - All CVEs are Alpine OS package issues, not Charon application code
 - No patches available from Alpine upstream as of 2026-01-13
 - Low exploitability in containerized deployment environment

docs/security/archive/VULNERABILITY_ASSESSMENT_PHASE2.md

@@ -29,11 +29,13 @@
 The golang.org/x/crypto/ssh package contains a vulnerability where improper use of the ServerConfig.PublicKeyCallback function could lead to authorization bypass. This is particularly critical for applications using SSH key-based authentication.
 
 **Risk Assessment:**
+
 - **Likelihood:** Medium (requires specific misuse pattern)
 - **Impact:** High (authorization bypass possible)
 - **Overall Risk:** HIGH
 
 **Remediation:**
+
 ```bash
 # Update crypto package to latest version
 go get -u golang.org/x/crypto@latest
@@ -46,6 +48,7 @@ go list -m golang.org/x/crypto
 ```
 
 **Verification Steps:**
+
 1. Run: `go mod tidy`
 2. Run: `trivy fs . --severity CRITICAL --format json | jq '.Results[] | select(.Vulnerabilities!=null) | .Vulnerabilities[] | select(.VulnerabilityID=="CVE-2024-45337")'`
 3. Confirm vulnerability no longer appears
@@ -249,6 +252,7 @@ git push
 ### Automated Dependency Updates
 
 **Recommended Setup:**
+
 1. Enable Dependabot on GitHub
 2. Set up automatic PR creation for security updates
 3. Configure CI to run on dependency PRs
@@ -257,6 +261,7 @@ git push
 ### Configuration
 
 **.github/dependabot.yml:**
+
 ```yaml
 version: 2
 updates:
@@ -305,6 +310,7 @@ updates:
 ## Timeline & Tracking
 
 ### Phase 1: Immediate (Today)
+
 - [ ] Review this report
 - [ ] Run remediation steps
 - [ ] Verify updates resolve CVEs
@@ -312,12 +318,14 @@ updates:
 - [ ] Commit and push updates
 
 ### Phase 2: Within 1 Week
+
 - [ ] Test updated dependencies
 - [ ] Run full E2E test suite
 - [ ] Performance verification
 - [ ] Deploy to staging
 
 ### Phase 3: Within 2 Weeks
+
 - [ ] Deploy to production
 - [ ] Monitor for issues
 - [ ] Set up automated scanning

docs/security/archive/accessibility_remediation_crowdsec.md

@@ -25,11 +25,13 @@ The CrowdSec "Ban IP" and "Unban IP" modals were identified as lacking standard
 Verification was performed using the Playwright E2E test suite running against a Dockerized environment.
 
 ### Test Environment
+
 - **Container**: `charon-e2e`
 - **Base URL**: `http://localhost:8080`
 - **Browser**: Firefox
 
 ### Test Execution
+
 **Command**: `npx playwright test tests/security/crowdsec-decisions.spec.ts -g "should open ban modal"`
 
 **Result**: ✅ **PASSED**
@@ -49,6 +51,7 @@ A broader run of `tests/security/crowdsec-decisions.spec.ts` was also executed,
 ## 4. Code Snippets
 
 ### Ban Modal
+
 ```tsx
 <div
   className="fixed inset-0 z-50 flex items-center justify-center"

docs/security/archive/advisory_2026-02-01_base_image_cves.md

@@ -15,6 +15,7 @@
 **This risk acceptance expires on May 2, 2026.**
 
 A fresh security review **MUST** be conducted before the expiration date to:
+
 - ✅ Verify patch availability from Debian Security
 - ✅ Re-assess risk level based on new threat intelligence
 - ✅ Renew or revoke this risk acceptance
@@ -27,6 +28,7 @@ A fresh security review **MUST** be conducted before the expiration date to:
 ## Executive Summary
 
 **Vulnerability Overview**:
+
 - **Total Vulnerabilities Detected**: 409
 - **HIGH Severity**: 7 (requires documentation and monitoring)
 - **Patches Available**: 0 (all HIGH CVEs unpatched as of February 1, 2026)
@@ -63,11 +65,13 @@ All HIGH severity vulnerabilities are in Debian Trixie base image system librari
 A heap overflow vulnerability exists in the memory alignment functions (`memalign`, `aligned_alloc`, `posix_memalign`) of GNU C Library (glibc). Exploitation requires an attacker to control the size or alignment parameters passed to these functions.
 
 **Charon Impact**: **MINIMAL**
+
 - Charon does not directly call `memalign` or related functions
 - Go's runtime memory allocator does not use these glibc functions for heap management
 - Attack requires direct control of memory allocation parameters
 
 **Exploitation Complexity**: **HIGH**
+
 - Requires vulnerable application code path
 - Attacker must control function parameters
 - Heap layout manipulation needed
@@ -84,12 +88,14 @@ A heap overflow vulnerability exists in the memory alignment functions (`memalig
 A stack buffer overflow exists in the ASN.1 parsing library (libtasn1) when processing maliciously crafted ASN.1 encoded data. This library is used by TLS/SSL implementations for certificate parsing.
 
 **Charon Impact**: **MINIMAL**
+
 - Charon uses Go's native `crypto/tls` package, not system libtasn1
 - Attack requires malformed TLS certificates presented to the application
 - Go's ASN.1 parser is memory-safe and not affected by this CVE
 - System libtasn1 is only used by OS-level services (e.g., system certificate validation)
 
 **Exploitation Complexity**: **HIGH**
+
 - Requires attacker-controlled certificate uploaded or presented
 - Go's TLS stack provides defense-in-depth
 
@@ -105,12 +111,14 @@ A stack buffer overflow exists in the ASN.1 parsing library (libtasn1) when proc
 The `wordexp()` function in glibc, when used with the `WRDE_REUSE` flag, can lead to improper memory management. This function performs shell-like word expansion and is typically used to parse configuration files or user input.
 
 **Charon Impact**: **NONE**
+
 - Charon is written in Go, does not call glibc `wordexp()`
 - Go's standard library does not use `wordexp()` internally
 - No shell expansion performed by Charon application code
 - Attack requires application to call vulnerable glibc function
 
 **Exploitation Complexity**: **VERY HIGH**
+
 - Requires vulnerable C/C++ application using `wordexp(WRDE_REUSE)`
 - Charon (Go) is not affected
 
@@ -126,12 +134,14 @@ The `wordexp()` function in glibc, when used with the `WRDE_REUSE` flag, can lea
 A vulnerability in the Name Service Switch (NSS) subsystem's handling of network address resolution (`getnetbyaddr`) can be exploited through malicious `nsswitch.conf` configurations.
 
 **Charon Impact**: **MINIMAL**
+
 - Charon uses Go's `net` package for DNS resolution, not glibc NSS
 - Go's resolver does not parse `/etc/nsswitch.conf`
 - Attack requires root/container escape to modify system configuration
 - Charon runs as non-root user with read-only filesystem
 
 **Exploitation Complexity**: **VERY HIGH**
+
 - Requires root access to modify `/etc/nsswitch.conf`
 - If attacker has root, this CVE is not the primary concern
 
@@ -208,6 +218,7 @@ A vulnerability in the Name Service Switch (NSS) subsystem's handling of network
 6. **Alternative Complexity**: Migrating to Alpine Linux requires significant testing effort
 
 **Acceptance Conditions**:
+
 - ✅ Weekly Grype scans to monitor for patches
 - ✅ Subscription to Debian Security Announce mailing list
 - ✅ 90-day re-evaluation mandatory (expires May 2, 2026)
@@ -236,6 +247,7 @@ cap_add:
 ```
 
 **Rationale**:
+
 - **`no-new-privileges`**: Prevents privilege escalation via setuid binaries
 - **Read-only filesystem**: Prevents modification of system libraries or binaries
 - **Non-root user**: Limits impact of container escape
@@ -244,12 +256,14 @@ cap_add:
 #### Application-Level Security
 
 **Cerberus Security Suite** (enabled in production):
+
 - ✅ **WAF (Coraza)**: Blocks common attack payloads (SQLi, XSS, RCE)
 - ✅ **ACL**: IP-based access control to admin interface
 - ✅ **Rate Limiting**: Prevents brute-force and DoS attempts
 - ✅ **CrowdSec**: Community-driven threat intelligence and IP reputation
 
 **TLS Configuration**:
+
 - ✅ TLS 1.3 minimum (enforced by Caddy reverse proxy)
 - ✅ Strong cipher suites only (no weak ciphers)
 - ✅ HTTP Strict Transport Security (HSTS)
@@ -258,6 +272,7 @@ cap_add:
 #### Network Security
 
 **Firewall Rules** (example for production deployment):
+
 ```bash
 # Allow only HTTPS and SSH
 iptables -A INPUT -p tcp --dport 443 -j ACCEPT
@@ -280,6 +295,7 @@ iptables -A FORWARD -i docker0 -o eth0 -d 10.0.0.0/8 -j DROP  # Block internal n
 **CI Integration**: GitHub Actions workflow
 
 **Workflow**:
+
 ```yaml
 # .github/workflows/security-scan-weekly.yml
 name: Weekly Security Scan
@@ -300,6 +316,7 @@ jobs:
 ```
 
 **Alert Triggers**:
+
 - ✅ Patch available for any HIGH CVE → Create PR automatically
 - ✅ New CRITICAL CVE discovered → Slack/email alert to security team
 - ✅ 7 days before expiration (April 25, 2026) → Calendar reminder
@@ -308,11 +325,12 @@ jobs:
 
 ### Debian Security Mailing List Subscription
 
-**Mailing List**: security-announce@lists.debian.org
-**Subscriber**: security-team@example.com
+**Mailing List**: <security-announce@lists.debian.org>
+**Subscriber**: <security-team@example.com>
 **Filter Rule**: Flag emails mentioning CVE-2026-0861, CVE-2025-13151, CVE-2025-15281, CVE-2026-0915
 
 **Response SLA**:
+
 - **Patch announced**: Review and test within 48 hours
 - **Backport required**: Create PR within 5 business days
 - **Breaking change**: Schedule maintenance window within 2 weeks
@@ -336,9 +354,10 @@ jobs:
    - 🟠 **High Priority**: Assess impact and plan migration to Alpine Linux if needed
 
 **Contact List**:
-- Security Team Lead: security-lead@example.com
-- DevOps On-Call: oncall-devops@example.com
-- CTO: cto@example.com
+
+- Security Team Lead: <security-lead@example.com>
+- DevOps On-Call: <oncall-devops@example.com>
+- CTO: <cto@example.com>
 
 ---
 
@@ -347,18 +366,21 @@ jobs:
 ### Alpine Linux (Considered for Future Migration)
 
 **Advantages**:
+
 - ✅ Smaller attack surface (~5MB vs. ~120MB Debian base)
 - ✅ musl libc (not affected by glibc CVEs)
 - ✅ Faster security updates
 - ✅ Immutable infrastructure friendly
 
 **Disadvantages**:
+
 - ❌ Different C library (musl) - potential compatibility issues
 - ❌ Limited pre-built binary packages (Go binaries are fine)
 - ❌ Less mature ecosystem vs. Debian
 - ❌ Requires extensive regression testing
 
 **Decision**: Defer Alpine migration until:
+
 - Debian Trixie reaches end-of-life, OR
 - CRITICAL unpatched CVE with active exploit
 
@@ -401,22 +423,24 @@ For use during compliance audits (SOC 2, ISO 27001, etc.):
 
 ### Vulnerability Trackers
 
-- **Debian Security Tracker**: https://security-tracker.debian.org/tracker/
-- **CVE-2026-0861**: https://security-tracker.debian.org/tracker/CVE-2026-0861
-- **CVE-2025-13151**: https://security-tracker.debian.org/tracker/CVE-2025-13151
-- **CVE-2025-15281**: https://security-tracker.debian.org/tracker/CVE-2025-15281
-- **CVE-2026-0915**: https://security-tracker.debian.org/tracker/CVE-2026-0915
+- **Debian Security Tracker**: <https://security-tracker.debian.org/tracker/>
+- **CVE-2026-0861**: <https://security-tracker.debian.org/tracker/CVE-2026-0861>
+- **CVE-2025-13151**: <https://security-tracker.debian.org/tracker/CVE-2025-13151>
+- **CVE-2025-15281**: <https://security-tracker.debian.org/tracker/CVE-2025-15281>
+- **CVE-2026-0915**: <https://security-tracker.debian.org/tracker/CVE-2026-0915>
 
 ### Scan Results
 
 **Grype Scan Executed**: February 1, 2026
 **Scan Command**:
+
 ```bash
 grype charon:latest -o json > grype-results.json
 grype charon:latest -o sarif > grype-results.sarif
 ```
 
 **Full Results**:
+
 - JSON: `/projects/Charon/grype-results.json`
 - SARIF: `/projects/Charon/grype-results.sarif`
 - Summary: 409 total vulnerabilities (0 Critical, 7 High, 20 Medium, 2 Low, 380 Negligible)

docs/security/archive/advisory_2026-02-04_debian_cves_temporary.md

@@ -26,12 +26,14 @@ During Docker image security scanning, 7 HIGH severity CVEs were identified in t
 **Actual Risk Level**: 🟢 **LOW**
 
 **Justification**:
+
 - CVEs affect Debian system libraries, NOT application code
 - No direct exploit paths identified in Charon's usage patterns
 - Application runs in isolated container environment
 - User-facing services do not expose vulnerable library functionality
 
 **Mitigating Factors**:
+
 1. Container isolation limits exploit surface area
 2. Charon does not directly invoke vulnerable libc/libtiff functions
 3. Network ingress filtered through Caddy proxy
@@ -42,6 +44,7 @@ During Docker image security scanning, 7 HIGH severity CVEs were identified in t
 **Strategy**: Migrate back to Alpine Linux base image
 
 **Timeline**:
+
 - **Week 1 (Feb 5-8)**: Verify Alpine CVE-2025-60876 is patched
 - **Weeks 2-3 (Feb 11-22)**: Dockerfile migration + comprehensive testing
 - **Week 4 (Feb 26-28)**: Staging deployment validation
@@ -64,6 +67,7 @@ During Docker image security scanning, 7 HIGH severity CVEs were identified in t
 ### Why Not Block?
 
 Blocking the CrowdSec fix would:
+
 - Leave user's production environment broken
 - Provide ZERO security improvement (CVEs pre-exist in all branches)
 - Delay critical authentication fixes unrelated to base image
@@ -72,17 +76,20 @@ Blocking the CrowdSec fix would:
 ## Monitoring
 
 **Continuous Tracking**:
+
 - Debian security advisories (daily monitoring)
 - Alpine CVE status (Phase 1 gate: must be clean)
 - Exploit database updates (CISA KEV, Exploit-DB)
 
 **Alerting**:
+
 - Notify if Debian releases patches (expedite Alpine migration)
 - Alert if active exploits published (emergency Alpine migration)
 
 ## User Communication
 
 **Transparency Commitment**:
+
 - Document in CHANGELOG.md
 - Include in release notes
 - Update SECURITY.md with mitigation timeline
@@ -99,6 +106,7 @@ Blocking the CrowdSec fix would:
 ---
 
 **References**:
+
 - Alpine Migration Spec: [`docs/plans/alpine_migration_spec.md`](../plans/alpine_migration_spec.md)
 - QA Report: [`docs/reports/qa_report.md`](../reports/qa_report.md)
 - Vulnerability Acceptance Policy: [`docs/security/VULNERABILITY_ACCEPTANCE.md`](VULNERABILITY_ACCEPTANCE.md)

docs/security/archive/api-key-handling.md

@@ -33,6 +33,7 @@ The `maskAPIKey()` function implements these rules:
 3. **Normal keys (≥ 16 chars)**: Shows first 4 + last 4 characters (e.g., `abcd...xyz9`)
 
 These rules ensure that:
+
 - Keys cannot be reconstructed from logs
 - Users can still identify which key was used (by prefix/suffix)
 - Debugging remains possible without exposing secrets
@@ -49,6 +50,7 @@ err := os.WriteFile(keyFile, []byte(apiKey), 0600)
 ```
 
 **Required permissions**: `0600` (rw-------)
+
 - Owner: read + write
 - Group: no access
 - Others: no access
@@ -96,6 +98,7 @@ strings.Repeat("a", 129)              // ❌ Too long (> 128 chars)
 ### Log Aggregation Risks
 
 If logs are shipped to external services (CloudWatch, Splunk, Datadog, etc.):
+
 - Masked keys are safe to log
 - Full keys would be exposed across multiple systems
 - Log retention policies apply to all destinations
@@ -148,11 +151,13 @@ c.JSON(200, gin.H{
 ### Rotation Procedure
 
 1. Generate new bouncer in CrowdSec:
+
    ```bash
    cscli bouncers add new-bouncer-name
    ```
 
 2. Update Charon configuration:
+
    ```bash
    # Update environment variable
    CHARON_SECURITY_CROWDSEC_API_KEY=new-key-here
@@ -165,6 +170,7 @@ c.JSON(200, gin.H{
 3. Restart Charon to apply new key
 
 4. Revoke old bouncer:
+
    ```bash
    cscli bouncers delete old-bouncer-name
    ```
@@ -233,6 +239,7 @@ go test ./backend/internal/api/handlers -run TestSaveKeyToFile_SecurePermissions
 ### Test Scenarios
 
 Tests cover:
+
 - ✅ Empty keys → `[empty]`
 - ✅ Short keys (< 16) → `[REDACTED]`
 - ✅ Normal keys → `abcd...xyz9`

docs/security/ghsa-69x3-g4r3-p962-options.md

@@ -158,6 +158,7 @@ These checks help estimate practical risk and verify assumptions. They do **not*
 7. Reassess exception validity on each CI security scan cycle.
 
 ## Notes
+
 - As of the testing on 2026-02-19, just updating nebula to `1.10.3` in the Dockerfile causes build failures due to upstream incompatibilities, which supports the attribution and reproduction evidence for the temporary exception path.
 - The conflict between `smallstep/certificates` and `nebula` API changes is a known issue in the ecosystem, which adds external validity to the hypothesis about the dependency chain.
 - Will need to monitor upstream releases of `smallstep/certificates` and `Caddy` for compatible versions that allow upgrading `nebula` without breaking builds.

docs/testing/DEBUGGING_IMPLEMENTATION.md

@@ -16,6 +16,7 @@ A complete debugging ecosystem has been implemented to provide maximum observabi
 **File**: `tests/utils/debug-logger.ts` (291 lines)
 
 **Features**:
+
 - Class-based logger with methods: `step()`, `network()`, `pageState()`, `locator()`, `assertion()`, `error()`
 - Automatic duration tracking for operations
 - Color-coded console output for local runs (ANSI colors)
@@ -26,6 +27,7 @@ A complete debugging ecosystem has been implemented to provide maximum observabi
 - Integration with Playwright test.step() system
 
 **Key Methods**:
+
 ```typescript
 step(name: string, duration?: number)           // Log test steps
 network(entry: NetworkLogEntry)                 // Log HTTP activity
@@ -38,6 +40,7 @@ printSummary()                                  // Print colored summary to cons
 ```
 
 **Output Example**:
+
 ```
 ├─ Navigate to home page
 ├─ Fill login form (234ms)
@@ -51,6 +54,7 @@ printSummary()                                  // Print colored summary to cons
 **File**: `tests/global-setup.ts` (Updated with timing logs)
 
 **Enhancements**:
+
 - Timing information for health checks (all operations timed)
 - Port connectivity checks with timing (Caddy admin, emergency server)
 - IPv4 vs IPv6 detection in URL parsing
@@ -60,6 +64,7 @@ printSummary()                                  // Print colored summary to cons
 - Error context on failures with next steps
 
 **Sample Output**:
+
 ```
 🔍 Checking Caddy admin API health at http://localhost:2019...
   ✅ Caddy admin API (port 2019) is healthy [45ms]
@@ -76,6 +81,7 @@ printSummary()                                  // Print colored summary to cons
 **File**: `playwright.config.js` (Updated)
 
 **Enhancements**:
+
 - `trace: 'on-first-retry'` - Captures traces for all retries (not just first)
 - `video: 'retain-on-failure'` - Records videos only for failed tests
 - `screenshot: 'only-on-failure'` - Screenshots on failure only
@@ -83,6 +89,7 @@ printSummary()                                  // Print colored summary to cons
 - Comprehensive comments explaining each option
 
 **Configuration Added**:
+
 ```javascript
 use: {
   trace: process.env.CI ? 'on-first-retry' : 'on-first-retry',
@@ -96,6 +103,7 @@ use: {
 **File**: `tests/reporters/debug-reporter.ts` (130 lines)
 
 **Features**:
+
 - Parses test step execution and identifies slow operations (>5s)
 - Aggregates failures by type (timeout, assertion, network, locator)
 - Generates structured summary output to stdout
@@ -104,6 +112,7 @@ use: {
 - Creates visual bar charts for failure distribution
 
 **Sample Output**:
+
 ```
 ╔════════════════════════════════════════════════════════════╗
 ║              E2E Test Execution Summary                      ║
@@ -130,6 +139,7 @@ network      │ ░░░░░░░░░░░░░░░░░░░░  1
 **File**: `tests/fixtures/network.ts` (286 lines)
 
 **Features**:
+
 - Intercepts all HTTP requests and responses
 - Tracks metrics per request:
   - URL, method, status code, elapsed time
@@ -150,6 +160,7 @@ network      │ ░░░░░░░░░░░░░░░░░░░░  1
 - Per-test request logging to debug logger
 
 **Export Example**:
+
 ```csv
 "Timestamp","Method","URL","Status","Duration (ms)","Content-Type","Body Size","Error"
 "2024-01-27T10:30:45.123Z","GET","https://api.example.com/health","200","45","application/json","234",""
@@ -161,6 +172,7 @@ network      │ ░░░░░░░░░░░░░░░░░░░░  1
 **File**: `tests/utils/test-steps.ts` (148 lines)
 
 **Features**:
+
 - `testStep()` - Wrapper around test.step() with automatic logging
 - `LoggedPage` - Page wrapper that logs all interactions
 - `testAssert()` - Assertion helper with logging
@@ -171,6 +183,7 @@ network      │ ░░░░░░░░░░░░░░░░░░░░  1
 - Performance tracking per test
 
 **Usage Example**:
+
 ```typescript
 await testStep('Login', async () => {
   await page.click('[role="button"]');
@@ -187,6 +200,7 @@ console.log(`Completed in ${result.duration}ms`);
 **File**: `.github/workflows/e2e-tests.yml` (Updated)
 
 **Environment Variables Added**:
+
 ```yaml
 env:
   DEBUG: 'charon:*,charon-test:*'
@@ -195,12 +209,14 @@ env:
 ```
 
 **Shard Step Enhancements**:
+
 - Per-shard start/end logging with timestamps
 - Shard duration tracking
 - Sequential output format for easy parsing
 - Status banner for each shard completion
 
 **Sample Shard Output**:
+
 ```
 ════════════════════════════════════════════════════════════
 E2E Test Shard 1/4
@@ -214,6 +230,7 @@ Shard 1 Complete | Duration: 125s
 ```
 
 **Job Summary Enhancements**:
+
 - Per-shard status table with timestamps
 - Test artifact locations (HTML report, videos, traces, logs)
 - Debugging tips for common scenarios
@@ -254,6 +271,7 @@ Shard 1 Complete | Duration: 125s
 **File**: `docs/testing/debugging-guide.md` (600+ lines)
 
 **Sections**:
+
 - Quick start for local testing
 - VS Code debug task usage guide
 - Debug logger method reference
@@ -265,6 +283,7 @@ Shard 1 Complete | Duration: 125s
 - Troubleshooting tips
 
 **Features**:
+
 - Code examples for all utilities
 - Sample output for each feature
 - Commands for common debugging tasks
@@ -276,6 +295,7 @@ Shard 1 Complete | Duration: 125s
 ## File Inventory
 
 ### Created Files (4)
+
 | File | Lines | Purpose |
 |------|-------|---------|
 | `tests/utils/debug-logger.ts` | 291 | Core debug logging utility |
@@ -287,6 +307,7 @@ Shard 1 Complete | Duration: 125s
 **Total New Code**: 1,455+ lines
 
 ### Modified Files (3)
+
 | File | Changes |
 |------|---------|
 | `tests/global-setup.ts` | Enhanced timing logs, error context, detailed output |
@@ -314,6 +335,7 @@ PLAYWRIGHT_BASE_URL=http://localhost:8080
 ### In CI (GitHub Actions)
 
 Set automatically in workflow:
+
 ```yaml
 env:
   DEBUG: 'charon:*,charon-test:*'
@@ -333,6 +355,7 @@ All new tasks are in the "test" group in VS Code:
 4. ✅ `Test: E2E Playwright - View Coverage Report`
 
 Plus existing tasks:
+
 - `Test: E2E Playwright (Chromium)`
 - `Test: E2E Playwright (All Browsers)`
 - `Test: E2E Playwright (Headed)`
@@ -434,6 +457,7 @@ Plus existing tasks:
 ### After Implementation
 
 ✅ **Local Debugging**
+
 - Interactive step-by-step debugging
 - Full trace capture with Playwright Inspector
 - Color-coded console output with timing
@@ -441,6 +465,7 @@ Plus existing tasks:
 - Automatic slow operation detection
 
 ✅ **CI Diagnostics**
+
 - Per-shard status tracking with timing
 - Failure categorization by type (timeout, assertion, network)
 - Aggregated statistics across all shards
@@ -448,6 +473,7 @@ Plus existing tasks:
 - Artifact collection for detailed analysis
 
 ✅ **Performance Analysis**
+
 - Per-operation duration tracking
 - Network request metrics (status, size, timing)
 - Automatic identification of slow operations (>5s)
@@ -455,6 +481,7 @@ Plus existing tasks:
 - Request/response size analysis
 
 ✅ **Network Visibility**
+
 - All HTTP requests logged
 - Status codes and response times tracked
 - Request/response headers (sanitized)
@@ -462,6 +489,7 @@ Plus existing tasks:
 - Error context with messages
 
 ✅ **Data Export**
+
 - Network logs as CSV for spreadsheet analysis
 - Structured JSON for programmatic access
 - Test metrics for trend analysis
@@ -487,6 +515,7 @@ Plus existing tasks:
 ## Next Steps for Users
 
 1. **Try Local Debugging**:
+
    ```bash
    npm run e2e -- --grep="test-name"
    ```
@@ -497,11 +526,13 @@ Plus existing tasks:
    - Select a debug task
 
 3. **View Test Reports**:
+
    ```bash
    npx playwright show-report
    ```
 
 4. **Inspect Traces**:
+
    ```bash
    npx playwright show-trace test-results/[test-name]/trace.zip
    ```

docs/testing/DEBUG_OUTPUT_EXAMPLES.md

@@ -5,6 +5,7 @@ This document explains how the new comprehensive debugging infrastructure helps
 ## What Changed: Before vs. After
 
 ### BEFORE: Generic Failure Output
+
 ```
   ✗ [chromium] › tests/settings/account-settings.spec.ts › should validate certificate email format
     Timeout 30s exceeded, waiting for expect(locator).toBeDisabled()
@@ -12,6 +13,7 @@ This document explains how the new comprehensive debugging infrastructure helps
 ```
 
 **Problem**: No information about:
+
 - What page was displayed when it failed
 - What network requests were in flight
 - What the actual button state was
@@ -22,6 +24,7 @@ This document explains how the new comprehensive debugging infrastructure helps
 ### AFTER: Rich Debug Logging Output
 
 #### 1. **Test Step Logging** (From enhanced global-setup.ts)
+
 ```
 ✅ Global setup complete
 
@@ -37,6 +40,7 @@ This document explains how the new comprehensive debugging infrastructure helps
 ```
 
 #### 2. **Network Activity Logging** (From network.ts interceptor)
+
 ```
 📡 Network Log (automatic)
 ────────────────────────────────────────────────────────────
@@ -52,6 +56,7 @@ Timestamp    │ Method │ URL                         │ Status │ Duration
 **Key Insight**: The 422 error on email update shows the API is rejecting the input, which explains why the button didn't disable—the form never validated successfully.
 
 #### 3. **Locator Matching Logs** (From debug-logger.ts)
+
 ```
 🎯 Locator Actions:
 ────────────────────────────────────────────────────────────
@@ -71,6 +76,7 @@ Timestamp    │ Method │ URL                         │ Status │ Duration
 **Key Insight**: The form wasn't visible in the DOM when the test tried to click the button.
 
 #### 4. **Assertion Logging** (From debug-logger.ts)
+
 ```
 ✓ Assert: "button is enabled" PASS          [15ms]
   └─ Expected: enabled=true
@@ -89,6 +95,7 @@ Timestamp    │ Method │ URL                         │ Status │ Duration
 **Key Insight**: The validation error exists but is hidden, so the button remains enabled. The test expected it to disable.
 
 #### 5. **Timing Analysis** (From debug reporter)
+
 ```
 📊 Test Timeline:
 ────────────────────────────────────────────────────────────
@@ -108,14 +115,17 @@ Timestamp    │ Method │ URL                         │ Status │ Duration
 ## How to Read the Debug Output in Playwright Report
 
 ### Step 1: Open the Report
+
 ```bash
 npx playwright show-report
 ```
 
 ### Step 2: Click Failed Test
+
 The test details page shows:
 
 **Console Logs Section**:
+
 ```
 [debug] 03:48:12.456: Step "Navigate to account settings"
 [debug]   └─ URL transitioned from / to /account
@@ -141,14 +151,18 @@ The test details page shows:
 ```
 
 ### Step 3: Check the Trace
+
 Click "Trace" tab:
+
 - **Timeline**: See each action with exact timing
 - **Network**: View all HTTP requests and responses
 - **DOM Snapshots**: Inspect page state at each step
 - **Console**: See browser console messages
 
 ### Step 4: Watch the Video
+
 The video shows:
+
 - What the user would have seen
 - Where the UI hung or stalled
 - If spinners/loading states appeared
@@ -157,9 +171,11 @@ The video shows:
 ## Failure Category Examples
 
 ### Category 1: Timeout Failures
+
 **Indicator**: `Timeout 30s exceeded, waiting for...`
 
 **Debug Output**:
+
 ```
 ⏱️  Operation Timeline:
   [03:48:14.000] ← Start waiting for locator
@@ -173,6 +189,7 @@ The video shows:
 **Diagnosis**: The network was slow (2.4s for a 50KB response). Test didn't wait long enough.
 
 **Fix**:
+
 ```javascript
 await page.waitForLoadState('networkidle'); // Wait for network before assertion
 await expect(locator).toBeVisible({timeout: 10000}); // Increase timeout
@@ -181,9 +198,11 @@ await expect(locator).toBeVisible({timeout: 10000}); // Increase timeout
 ---
 
 ### Category 2: Assertion Failures
+
 **Indicator**: `expect(locator).toBeDisabled() failed`
 
 **Debug Output**:
+
 ```
 ✋ Assertion failed: toBeDisabled()
   Expected: disabled=true
@@ -213,6 +232,7 @@ await expect(locator).toBeVisible({timeout: 10000}); // Increase timeout
 **Diagnosis**: The component's disable logic isn't working correctly.
 
 **Fix**:
+
 ```jsx
 // In React component:
 const isFormValid = !hasValidationErrors;
@@ -227,9 +247,11 @@ const isFormValid = !hasValidationErrors;
 ---
 
 ### Category 3: Locator Failures
+
 **Indicator**: `getByRole('button', {name: /save/i}): multiple elements found`
 
 **Debug Output**:
+
 ```
 🚨 Strict Mode Violation: Multiple elements matched
   Selector: getByRole('button', {name: /save/i})
@@ -255,6 +277,7 @@ const isFormValid = !hasValidationErrors;
 **Diagnosis**: Locator is too broad and matches multiple elements.
 
 **Fix**:
+
 ```javascript
 // ✅ Good: Scoped to dialog
 await page.getByRole('dialog').getByRole('button', {name: /save certificate/i}).click();
@@ -269,9 +292,11 @@ await page.getByRole('button', {name: /save/i}).click();
 ---
 
 ### Category 4: Network/API Failures
+
 **Indicator**: `API returned 422` or `POST /api/endpoint failed with 500`
 
 **Debug Output**:
+
 ```
 ❌ Network Error
   Request: POST /api/account/email
@@ -307,6 +332,7 @@ await page.getByRole('button', {name: /save/i}).click();
 **Diagnosis**: The API is working correctly, but the frontend error handling isn't working.
 
 **Fix**:
+
 ```javascript
 // In frontend error handler:
 try {
@@ -326,6 +352,7 @@ try {
 ## Real-World Example: The Certificate Email Test
 
 **Test Code** (simplified):
+
 ```javascript
 test('should validate certificate email format', async ({page}) => {
   await page.goto('/account');
@@ -344,6 +371,7 @@ test('should validate certificate email format', async ({page}) => {
 ```
 
 **Debug Output Sequence**:
+
 ```
 1️⃣  Navigate to /account
     ✅ Page loaded [1234ms]
@@ -399,6 +427,7 @@ test('should validate certificate email format', async ({page}) => {
 ```
 
 **How to Fix**:
+
 1. Check the `Account.tsx` form submission error handler
 2. Ensure API errors update form state: `setFormErrors(response.errors)`
 3. Ensure button disable logic: `disabled={Object.keys(formErrors).length > 0}`
@@ -433,6 +462,7 @@ other        │ ██░░░░░░░░░░░░░░░░░░ 2/
 ```
 
 **What this tells you**:
+
 - **36% Timeout**: Network is slow or test expectations unrealistic
 - **27% Assertion**: Component behavior wrong (disable logic, form state, etc.)
 - **18% Locator**: Selector strategy needs improvement

docs/testing/FAILURE_DIAGNOSIS_GUIDE.md

@@ -5,6 +5,7 @@ This guide explains how to use the comprehensive debugging infrastructure to dia
 ## Quick Access Tools
 
 ### 1. **Playwright HTML Report** (Visual Analysis)
+
 ```bash
 # When tests complete, open the report
 npx playwright show-report
@@ -14,6 +15,7 @@ npx playwright show-report --port 9323
 ```
 
 **What to look for:**
+
 - Click on each failed test
 - View the trace timeline (shows each action, network request, assertion)
 - Check the video recording to see exactly what went wrong
@@ -21,30 +23,35 @@ npx playwright show-report --port 9323
 - Check browser console logs
 
 ### 2. **Debug Logger CSV Export** (Network Analysis)
+
 ```bash
 # After tests complete, check for network logs in test-results
 find test-results -name "*.csv" -type f
 ```
 
 **What to look for:**
+
 - HTTP requests that failed or timed out
 - Slow network operations (>1000ms)
 - Authentication failures (401/403)
 - API response errors
 
 ### 3. **Trace Files** (Step-by-Step Replay)
+
 ```bash
 # View detailed trace for a failed test
 npx playwright show-trace test-results/[test-name]/trace.zip
 ```
 
 **Features:**
+
 - Pause and step through each action
 - Inspect DOM at any point
 - Review network timing
 - Check locator matching
 
 ### 4. **Video Recordings** (Visual Feedback Loop)
+
 - Located in: `test-results/.playwright-artifacts-1/`
 - Map filenames to test names in Playwright report
 - Watch to understand timing and UI state when failure occurred
@@ -54,24 +61,28 @@ npx playwright show-trace test-results/[test-name]/trace.zip
 Based on the summary showing "other" category failures, these issues likely fall into:
 
 ### Category A: Timing/Flakiness Issues
+
 - Tests intermittently fail due to timeouts
 - Elements not appearing in expected timeframe
 - **Diagnosis**: Check videos for loading spinners, network delays
 - **Fix**: Increase timeout or add wait for specific condition
 
 ### Category B: Locator Issues
+
 - Selectors matching wrong elements or multiple elements
 - Elements appearing in different UI states
 - **Diagnosis**: Check traces to see selector matching logic
 - **Fix**: Make selectors more specific or use role-based locators
 
 ### Category C: State/Data Issues
+
 - Form data not persisting
 - Navigation not working correctly
 - **Diagnosis**: Check network logs for API failures
 - **Fix**: Add wait for API completion, verify mock data
 
 ### Category D: Accessibility/Keyboard Navigation
+
 - Keyboard events not triggering actions
 - Focus not moving as expected
 - **Diagnosis**: Review traces for keyboard action handling
@@ -79,7 +90,7 @@ Based on the summary showing "other" category failures, these issues likely fall
 
 ## Step-by-Step Failure Analysis Process
 
-### For Each Failed Test:
+### For Each Failed Test
 
 1. **Get Test Name**
    - Open Playwright report
@@ -87,9 +98,11 @@ Based on the summary showing "other" category failures, these issues likely fall
    - Note the test file + test name
 
 2. **View the Trace**
+
    ```bash
    npx playwright show-trace test-results/[test-name-hash]/trace.zip
    ```
+
    - Go through each step
    - Note which step failed and why
    - Check the actual error message
@@ -129,60 +142,75 @@ Our debug logger outputs structured messages like:
 ## Common Failure Patterns & Solutions
 
 ### Pattern 1: "Timeout waiting for locator"
+
 **Cause**: Element not appearing within timeout
 **Diagnosis**:
+
 - Check video - is the page still loading?
 - Check network tab - any pending requests?
 - Check DOM snapshot - does element exist but hidden?
 
 **Solution**:
+
 - Add `await page.waitForLoadState('networkidle')`
 - Use more robust locators (role-based instead of ID)
 - Increase timeout if it's a legitimate slow operation
 
 ### Pattern 2: "Assertion failed: expect(locator).toBeDisabled()"
+
 **Cause**: Button not in expected state
 **Diagnosis**:
+
 - Check trace - what's the button's actual state?
 - Check console - any JS errors?
 - Check network - is a form submission in progress?
 
 **Solution**:
+
 - Add explicit wait: `await expect(button).toBeDisabled({timeout: 10000})`
 - Wait for preceding action: `await page.getByRole('button').click(); await page.waitForLoadState()`
 - Check form library state
 
 ### Pattern 3: "Strict mode violation: multiple elements found"
+
 **Cause**: Selector matches 2+ elements
 **Diagnosis**:
+
 - Check trace DOM snapshots - count matching elements
 - Check test file - is selector too broad?
 
 **Solution**:
+
 - Scope to container: `page.getByRole('dialog').getByRole('button', {name: 'Save'})`
 - Use .first() or .nth(0): `getByRole('button').first()`
 - Make selector more specific
 
 ### Pattern 4: "Element not found by getByRole(...)"
+
 **Cause**: Accessibility attributes missing
 **Diagnosis**:
+
 - Check DOM in trace - what tags/attributes exist?
 - Is it missing role attribute?
 - Is aria-label/aria-labelledby correct?
 
 **Solution**:
+
 - Add role attribute to element
 - Add accessible name (aria-label, aria-labelledby, or text content)
 - Use more forgiving selectors temporarily to confirm
 
 ### Pattern 5: "Test timed out after 30000ms"
+
 **Cause**: Test execution exceeded timeout
 **Diagnosis**:
+
 - Check videos - where did it hang?
 - Check traces - last action before timeout?
 - Check network - any concurrent long-running requests?
 
 **Solution**:
+
 - Break test into smaller steps
 - Add explicit waits between actions
 - Check for infinite loops or blocking operations
@@ -208,6 +236,7 @@ other        │ ██░░░░░░░░░░░░░░░░░░ 2/
 ```
 
 **Key insights:**
+
 - **Timeout**: Look for network delays or missing waits
 - **Assertion**: Check state management and form validation
 - **Locator**: Focus on selector robustness
@@ -216,6 +245,7 @@ other        │ ██░░░░░░░░░░░░░░░░░░ 2/
 ## Advanced Debugging Techniques
 
 ### 1. Run Single Failed Test Locally
+
 ```bash
 # Get exact test name from report, then:
 npx playwright test --grep "should show user status badges"
@@ -225,6 +255,7 @@ DEBUG=charon:* npx playwright test --grep "should show user status badges" --deb
 ```
 
 ### 2. Inspect Network Logs CSV
+
 ```bash
 # Convert CSV to readable format
 column -t -s',' tests/network-logs.csv | less
@@ -233,16 +264,19 @@ column -t -s',' tests/network-logs.csv | less
 ```
 
 ### 3. Compare Videos Side-by-Side
+
 - Download videos from test-results/.playwright-artifacts-1/
 - Open in VLC with playlist
 - Play at 2x speed to spot behavior differences
 
 ### 4. Check Browser Console
+
 - In trace player, click "Console" tab
 - Look for JS errors or warnings
 - Check for 404/500 API responses in network tab
 
 ### 5. Reproduce Locally with Same Conditions
+
 ```bash
 # Use the exact same seed (if randomization is involved)
 SEED=12345 npx playwright test --grep "failing-test"
@@ -256,6 +290,7 @@ npx playwright test --grep "failing-test" --project=chromium --debug
 If tests pass locally but fail in CI Docker container:
 
 ### Check Container Logs
+
 ```bash
 # View Docker container output
 docker compose -f .docker/compose/docker-compose.test.yml logs charon
@@ -265,12 +300,14 @@ docker compose logs --tail=50
 ```
 
 ### Compare Environments
+
 - Docker: Running on 0.0.0.0:8080
-- Local: Running on localhost:8080/http://127.0.0.1:8080
+- Local: Running on localhost:8080/<http://127.0.0.1:8080>
 - **Check**: Are there IPv4/IPv6 differences?
 - **Check**: Are there DNS resolution issues?
 
 ### Port Accessibility
+
 ```bash
 # From inside Docker, check if ports are accessible
 docker exec charon curl -v http://localhost:8080
@@ -281,6 +318,7 @@ docker exec charon curl -v http://localhost:2020
 ## Escalation Path
 
 ### When to Investigate Code
+
 - Same tests fail consistently (not flaky)
 - Error message points to specific feature
 - Video shows incorrect behavior
@@ -289,12 +327,14 @@ docker exec charon curl -v http://localhost:2020
 **Action**: Fix the code/feature being tested
 
 ### When to Improve Test
+
 - Tests flaky (fail 1 in 5 times)
 - Timeout errors on slow operations
 - Intermittent locator matching issues
 - **Action**: Add waits, use more robust selectors, increase timeouts
 
 ### When to Update Test Infrastructure
+
 - Port/networking issues
 - Authentication failures
 - Global setup incomplete

docs/testing/README.md

@@ -3,6 +3,7 @@
 > **Recent Updates**: See [Sprint 1 Improvements](sprint1-improvements.md) for information about recent E2E test reliability and performance enhancements (February 2026).
 
 ### Getting Started with E2E Tests
+
 - **Running Tests**: `npm run e2e`
 - **All Browsers**: `npm run e2e:all`
 - **Headed UI on headless Linux**: `npm run e2e:ui:headless-server` — see `docs/development/running-e2e.md` for details

docs/testing/crowdsec_auth_manual_verification.md

@@ -53,6 +53,7 @@ This document provides step-by-step procedures for manually verifying the Bug #1
    ```
 
    **Expected Output**:
+
    ```
    time="..." level=warning msg="Environment variable CHARON_SECURITY_CROWDSEC_API_KEY is set but invalid. Either remove it from docker-compose.yml or update it to match the auto-generated key. A new valid key will be generated and saved." masked_key=fake...345
    ```
@@ -82,11 +83,13 @@ This document provides step-by-step procedures for manually verifying the Bug #1
    ```
 
    **Expected Output**:
+
    ```
    time="..." level=info msg="CrowdSec bouncer authentication successful" masked_key="abcd...wxyz" source=file
    ```
 
 **Success Criteria**:
+
 - ✅ Warning logged about invalid env var
 - ✅ New key auto-generated and saved to `/app/data/crowdsec/bouncer_key`
 - ✅ Bouncer authenticates successfully with new key
@@ -119,6 +122,7 @@ This document provides step-by-step procedures for manually verifying the Bug #1
    ```
 
    **Expected Output**:
+
    ```
    time="..." level=info msg="LAPI not ready, retrying with backoff" attempt=1 error="connection refused" next_attempt_ms=500
    time="..." level=info msg="LAPI not ready, retrying with backoff" attempt=2 error="connection refused" next_attempt_ms=750
@@ -128,6 +132,7 @@ This document provides step-by-step procedures for manually verifying the Bug #1
 4. **Wait for LAPI to Start** (up to 30 seconds)
 
    Look for success message:
+
    ```
    time="..." level=info msg="CrowdSec bouncer authentication successful" masked_key="abcd...wxyz" source=file
    ```
@@ -142,6 +147,7 @@ This document provides step-by-step procedures for manually verifying the Bug #1
    **Expected**: HTTP 200 OK
 
 **Success Criteria**:
+
 - ✅ Logs show retry attempts with exponential backoff (500ms → 750ms → 1125ms → ...)
 - ✅ Connection succeeds after LAPI starts (within 30s max)
 - ✅ No immediate failure on first connection refused error
@@ -157,6 +163,7 @@ This document provides step-by-step procedures for manually verifying the Bug #1
 1. **Reproduce Pre-Fix Behavior** (for comparison - requires reverting to old code)
 
    With old code, setting invalid env var would cause:
+
    ```
    time="..." level=error msg="LAPI authentication failed" error="access forbidden (403)" key="[REDACTED]"
    ```
@@ -164,12 +171,14 @@ This document provides step-by-step procedures for manually verifying the Bug #1
 2. **Apply Fix and Repeat Scenario 1**
 
    With new code, same invalid env var should produce:
+
    ```
    time="..." level=warning msg="Environment variable CHARON_SECURITY_CROWDSEC_API_KEY is set but invalid..."
    time="..." level=info msg="CrowdSec bouncer authentication successful" masked_key="abcd...wxyz" source=file
    ```
 
 **Success Criteria**:
+
 - ✅ No "access forbidden" errors after auto-recovery
 - ✅ Bouncer connects successfully with auto-generated key
 
@@ -190,6 +199,7 @@ docker restart charon
 ```
 
 **Expected Log**:
+
 ```
 time="..." level=info msg="CrowdSec bouncer authentication successful" masked_key="vali...test" source=environment_variable
 ```
@@ -203,6 +213,7 @@ docker restart charon
 ```
 
 **Expected Log**:
+
 ```
 time="..." level=info msg="CrowdSec bouncer authentication successful" masked_key="abcd...wxyz" source=file
 ```
@@ -216,12 +227,14 @@ docker restart charon
 ```
 
 **Expected Log**:
+
 ```
 time="..." level=info msg="Registering new CrowdSec bouncer: caddy-bouncer"
 time="..." level=info msg="CrowdSec bouncer registration successful" masked_key="new-...123" source=auto_generated
 ```
 
 **Success Criteria**:
+
 - ✅ Logs clearly show `source=environment_variable`, `source=file`, or `source=auto_generated`
 - ✅ User can determine which key is active without reading code
 
@@ -240,6 +253,7 @@ time="..." level=info msg="CrowdSec bouncer registration successful" masked_key=
 **Cause**: CrowdSec process failed to start or crashed
 
 **Debug Steps**:
+
 1. Check LAPI process: `docker exec charon ps aux | grep crowdsec`
 2. Check LAPI logs: `docker exec charon cat /var/log/crowdsec/crowdsec.log`
 3. Verify config: `docker exec charon cat /etc/crowdsec/config.yaml`
@@ -249,6 +263,7 @@ time="..." level=info msg="CrowdSec bouncer registration successful" masked_key=
 **Cause**: Key not properly registered with LAPI
 
 **Resolution**:
+
 ```bash
 # List registered bouncers
 docker exec charon cscli bouncers list

docs/testing/debugging-guide.md

@@ -60,6 +60,7 @@ logger.step('Click login button', 245); // with duration in ms
 ```
 
 **Output:**
+
 ```
 ├─ Navigate to home page
 ├─ Click login button (245ms)
@@ -81,6 +82,7 @@ logger.network({
 ```
 
 **Output:**
+
 ```
 ✅ POST https://api.example.com/login [200] 342ms
 ```
@@ -94,6 +96,7 @@ logger.locator('[role="button"]', 'click', true, 45);
 ```
 
 **Output:**
+
 ```
 ✓ click "[role="button"]" 45ms
 ```
@@ -108,6 +111,7 @@ logger.assertion('URL is correct', false, 'http://old.com', 'http://new.com');
 ```
 
 **Output:**
+
 ```
 ✓ Assert: Button is visible
 ✗ Assert: URL is correct | expected: "http://new.com", actual: "http://old.com"
@@ -122,6 +126,7 @@ logger.error('Network request failed', new Error('TIMEOUT'), 1);
 ```
 
 **Output:**
+
 ```
 ❌ ERROR: Network request failed - TIMEOUT
 🔄 Recovery: 1 attempts remaining
@@ -134,6 +139,7 @@ Traces capture all interactions, network activity, and DOM snapshots. They're in
 ### Automatic Trace Capture
 
 Traces are automatically captured:
+
 - On first retry of failed tests
 - On failure when running locally (if configured)
 
@@ -166,6 +172,7 @@ npx playwright show-trace test-results/path/to/trace.zip
 ```
 
 The Trace Viewer shows:
+
 - **Timeline**: Chronological list of all actions
 - **Network**: HTTP requests/responses with full details
 - **Console**: Page JS console output
@@ -490,18 +497,21 @@ test('should toggle security features', async ({ page }) => {
 ```
 
 **Key Features**:
+
 - Automatically finds parent `<label>` element
 - Scrolls element into view (sticky header aware)
 - Cross-browser compatible (Chromium, Firefox, WebKit)
 - No `force: true` or hard-coded waits needed
 
 **When to Use**:
+
 - Any test that clicks Switch/Toggle components
 - Settings pages with enable/disable toggles
 - Security dashboard module toggles (CrowdSec, ACL, WAF, Rate Limiting)
 - Access lists and configuration toggles
 
 **References**:
+
 - [Implementation](../../tests/utils/ui-helpers.ts) - Full helper code
 - [QA Report](../reports/qa_report.md) - Test results and validation
 

docs/testing/e2e-best-practices.md

@@ -19,6 +19,7 @@
 ### ❌ AVOID: Polling in beforeEach Hooks
 
 **Anti-Pattern**:
+
 ```typescript
 test.beforeEach(async ({ page, adminUser }) => {
   await loginUser(page, adminUser);
@@ -37,6 +38,7 @@ test.beforeEach(async ({ page, adminUser }) => {
 ```
 
 **Why This Is Bad**:
+
 - Polls `/api/v1/feature-flags` endpoint **31 times** per test file (once per test)
 - With 12 parallel processes (4 shards × 3 browsers), causes API server bottleneck
 - Adds 310s minimum execution time per shard (31 tests × 10s timeout)
@@ -49,6 +51,7 @@ test.beforeEach(async ({ page, adminUser }) => {
 ### ✅ PREFER: Per-Test Verification Only When Toggled
 
 **Correct Pattern**:
+
 ```typescript
 test('should toggle Cerberus feature', async ({ page }) => {
   await test.step('Navigate to system settings', async () => {
@@ -74,12 +77,14 @@ test('should toggle Cerberus feature', async ({ page }) => {
 ```
 
 **Why This Is Better**:
+
 - API calls reduced by **90%** (from 31 per shard to 3-5 per shard)
 - Only tests that actually toggle flags incur the polling cost
 - Faster test execution (shards complete in <15 minutes vs >30 minutes)
 - Clearer test intent—verification is tied to the action that requires it
 
 **Rule of Thumb**:
+
 - **No toggle, no propagation check**: If a test reads flag state without changing it, don't poll.
 - **Toggle = verify**: Always verify propagation after toggling to ensure state change persisted.
 
@@ -90,6 +95,7 @@ test('should toggle Cerberus feature', async ({ page }) => {
 ### ❌ AVOID: Label-Only Locators
 
 **Anti-Pattern**:
+
 ```typescript
 await test.step('Verify Script path/command field appears', async () => {
   // ⚠️ PROBLEM: Fails in Firefox/WebKit
@@ -99,6 +105,7 @@ await test.step('Verify Script path/command field appears', async () => {
 ```
 
 **Why This Fails**:
+
 - Label locators depend on browser-specific DOM rendering
 - Firefox/WebKit may render Label components differently than Chromium
 - Regex patterns may not match if label has extra whitespace or is split across nodes
@@ -109,6 +116,7 @@ await test.step('Verify Script path/command field appears', async () => {
 ### ✅ PREFER: Multi-Strategy Locators with Fallbacks
 
 **Correct Pattern**:
+
 ```typescript
 import { getFormFieldByLabel } from './utils/ui-helpers';
 
@@ -127,6 +135,7 @@ await test.step('Verify Script path/command field appears', async () => {
 ```
 
 **Helper Implementation** (`tests/utils/ui-helpers.ts`):
+
 ```typescript
 /**
  * Get form field with cross-browser label matching
@@ -169,12 +178,14 @@ export function getFormFieldByLabel(
 ```
 
 **Why This Is Better**:
+
 - **95%+ pass rate** on Firefox/WebKit (up from 70%)
 - Gracefully degrades through fallback strategies
 - No browser-specific workarounds needed in test code
 - Single helper enforces consistent pattern across all tests
 
 **When to Use**:
+
 - Any test that interacts with form fields
 - Tests that must pass on all three browsers (Chromium, Firefox, WebKit)
 - Accessibility-critical tests (label locators are user-facing)
@@ -186,6 +197,7 @@ export function getFormFieldByLabel(
 ### ❌ AVOID: Duplicate API Requests
 
 **Anti-Pattern**:
+
 ```typescript
 // Multiple tests in parallel all polling the same endpoint
 test('test 1', async ({ page }) => {
@@ -198,6 +210,7 @@ test('test 2', async ({ page }) => {
 ```
 
 **Why This Is Bad**:
+
 - 12 parallel workers all hit `/api/v1/feature-flags` simultaneously
 - No request coalescing or caching
 - API server degrades under concurrent load
@@ -208,6 +221,7 @@ test('test 2', async ({ page }) => {
 ### ✅ PREFER: Request Coalescing with Worker Isolation
 
 **Correct Pattern** (`tests/utils/wait-helpers.ts`):
+
 ```typescript
 // Cache in-flight requests per worker
 const inflightRequests = new Map<string, Promise<Record<string, boolean>>>();
@@ -249,12 +263,14 @@ export async function waitForFeatureFlagPropagation(
 ```
 
 **Why This Is Better**:
+
 - **30-40% reduction** in duplicate API calls
 - Multiple tests requesting same state share one API call
 - Worker isolation prevents cache collisions between parallel processes
 - Sorted keys ensure semantic equivalence (`{a:true, b:false}` === `{b:false, a:true}`)
 
 **Cache Behavior**:
+
 - **Hit**: Another test in same worker already polling for same state
 - **Miss**: First test in worker to request this state OR different state requested
 - **Clear**: Cache cleared after all tests in worker complete (`test.afterAll()`)
@@ -266,6 +282,7 @@ export async function waitForFeatureFlagPropagation(
 ### ❌ PROBLEM: Shards Exceeding Timeout
 
 **Symptom**:
+
 ```bash
 # GitHub Actions logs
 Error: The operation was canceled.
@@ -273,6 +290,7 @@ Job duration: 31m 45s (exceeds 30m limit)
 ```
 
 **Root Causes**:
+
 1. Feature flag polling in beforeEach (31 tests × 10s = 310s minimum)
 2. API bottleneck under parallel load
 3. Slow browser startup in CI environment
@@ -283,6 +301,7 @@ Job duration: 31m 45s (exceeds 30m limit)
 ### ✅ SOLUTION: Enforce 15-Minute Budget Per Shard
 
 **CI Configuration** (`.github/workflows/e2e-tests.yml`):
+
 ```yaml
 - name: Verify shard performance budget
   if: always()
@@ -300,23 +319,30 @@ Job duration: 31m 45s (exceeds 30m limit)
 ```
 
 **Why This Is Better**:
+
 - **Early detection** of performance regressions in CI
 - Forces developers to optimize slow tests before merge
 - Prevents accumulation of "death by a thousand cuts" slowdowns
 - Clear failure message directs investigation to bottleneck
 
 **How to Debug Timeouts**:
+
 1. **Check metrics**: Review API call counts in test output
+
    ```bash
    grep "CACHE HIT\|CACHE MISS" test-output.log
    ```
+
 2. **Profile locally**: Instrument slow helpers
+
    ```typescript
    const startTime = Date.now();
    await waitForLoadingComplete(page);
    console.log(`Loading took ${Date.now() - startTime}ms`);
    ```
+
 3. **Isolate shard**: Run failing shard locally to reproduce
+
    ```bash
    npx playwright test --shard=2/4 --project=firefox
    ```
@@ -328,6 +354,7 @@ Job duration: 31m 45s (exceeds 30m limit)
 ### ❌ AVOID: State Leakage Between Tests
 
 **Anti-Pattern**:
+
 ```typescript
 test('enable Cerberus', async ({ page }) => {
   await toggleCerberus(page, true);
@@ -342,6 +369,7 @@ test('ACL settings require Cerberus', async ({ page }) => {
 ```
 
 **Why This Is Bad**:
+
 - Tests depend on execution order (serial execution works, parallel fails)
 - Flakiness when running with `--workers=4` or `--repeat-each=5`
 - Hard to debug failures (root cause is in different test file)
@@ -351,6 +379,7 @@ test('ACL settings require Cerberus', async ({ page }) => {
 ### ✅ PREFER: Explicit State Restoration
 
 **Correct Pattern**:
+
 ```typescript
 test.afterEach(async ({ page }) => {
   await test.step('Restore default feature flag state', async () => {
@@ -375,12 +404,14 @@ test.afterEach(async ({ page }) => {
 ```
 
 **Why This Is Better**:
+
 - **Zero inter-test dependencies**: Tests can run in any order
 - Passes randomization testing: `--repeat-each=5 --workers=4`
 - Explicit cleanup makes state management visible in code
 - Fast restoration (no polling required, direct API call)
 
 **Validation Command**:
+
 ```bash
 # Verify test isolation with randomization
 npx playwright test tests/settings/system-settings.spec.ts \
@@ -398,6 +429,7 @@ npx playwright test tests/settings/system-settings.spec.ts \
 ### ❌ AVOID: Boolean Logic on Transient States
 
 **Anti-Pattern**:
+
 ```typescript
 const hasEmptyMessage = await emptyCellMessage.isVisible().catch(() => false);
 const hasTable = await table.isVisible().catch(() => false);
@@ -405,6 +437,7 @@ expect(hasEmptyMessage || hasTable).toBeTruthy();
 ```
 
 **Why This Is Bad**:
+
 - Fails during the split second where neither element is fully visible (loading transitions).
 - Playwright's auto-retrying logic is bypassed by the `catch()` block.
 - Leads to flaky "false negatives" where both checks return false before content loads.
@@ -412,6 +445,7 @@ expect(hasEmptyMessage || hasTable).toBeTruthy();
 ### ✅ PREFER: Locator Composition with `.or()`
 
 **Correct Pattern**:
+
 ```typescript
 await expect(
   page.getByRole('table').or(page.getByText(/no.*certificates.*found/i))
@@ -419,6 +453,7 @@ await expect(
 ```
 
 **Why This Is Better**:
+
 - Leverages Playwright's built-in **auto-retry** mechanism.
 - Waits for *either* condition to become true.
 - Handles loading spinners and layout shifts gracefully.
@@ -431,6 +466,7 @@ await expect(
 ### ❌ AVOID: Fixed Timeouts or Custom Loops
 
 **Anti-Pattern**:
+
 ```typescript
 // Flaky custom retry loop
 for (let i = 0; i < 3; i++) {
@@ -446,6 +482,7 @@ for (let i = 0; i < 3; i++) {
 ### ✅ PREFER: `.toPass()` for Verification Loops
 
 **Correct Pattern**:
+
 ```typescript
 await expect(async () => {
   const response = await request.post('/endpoint');
@@ -457,6 +494,7 @@ await expect(async () => {
 ```
 
 **Why This Is Better**:
+
 - Built-in assertion retry logic.
 - Configurable backoff intervals.
 - Cleaner syntax for verifying eventual success (e.g. valid API response after background processing).

docs/testing/e2e-dns-provider-triage-report.md

@@ -11,6 +11,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 ## Test Results
 
 ### Before Fixes
+
 | Status | Count |
 |--------|-------|
 | ❌ Failed | 7 |
@@ -18,6 +19,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | ⏭️ Skipped | 3 |
 
 ### After Fixes
+
 | Status | Count |
 |--------|-------|
 | ❌ Failed | 0 |
@@ -27,12 +29,15 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 ## Test Files Summary
 
 ### 1. `tests/auth.setup.ts`
+
 | Test | Status |
 |------|--------|
 | authenticate | ✅ Pass |
 
 ### 2. `tests/dns-provider-types.spec.ts`
+
 **API Tests:**
+
 | Test | Status |
 |------|--------|
 | GET /dns-providers/types returns all built-in and custom providers | ✅ Pass |
@@ -43,6 +48,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Script provider type has command/path field | ✅ Pass |
 
 **UI Tests:**
+
 | Test | Status |
 |------|--------|
 | Provider selector shows all provider types in dropdown | ✅ Pass |
@@ -54,7 +60,9 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Script type selection shows script path field | ✅ Pass |
 
 ### 3. `tests/dns-provider-crud.spec.ts`
+
 **Create Provider:**
+
 | Test | Status |
 |------|--------|
 | Create Manual DNS provider | ✅ Pass |
@@ -63,6 +71,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Validate webhook URL format | ✅ Pass |
 
 **Provider List:**
+
 | Test | Status |
 |------|--------|
 | Display provider list or empty state | ✅ Pass |
@@ -70,17 +79,20 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Show provider details in list | ✅ Pass |
 
 **Edit Provider:**
+
 | Test | Status |
 |------|--------|
 | Open edit dialog for existing provider | ⏭️ Skipped (conditional) |
 | Update provider name | ⏭️ Skipped (conditional) |
 
 **Delete Provider:**
+
 | Test | Status |
 |------|--------|
 | Show delete confirmation dialog | ⏭️ Skipped (conditional) |
 
 **API Operations:**
+
 | Test | Status |
 |------|--------|
 | List providers via API | ✅ Pass |
@@ -89,6 +101,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Get single provider via API | ✅ Pass |
 
 **Form Accessibility:**
+
 | Test | Status |
 |------|--------|
 | Form has accessible labels | ✅ Pass |
@@ -96,7 +109,9 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Errors announced to screen readers | ✅ Pass |
 
 ### 4. `tests/manual-dns-provider.spec.ts`
+
 **Provider Selection Flow:**
+
 | Test | Status |
 |------|--------|
 | Navigate to DNS Providers page | ✅ Pass |
@@ -104,6 +119,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Display Manual option in provider selection | ✅ Pass (Fixed) |
 
 **Manual Challenge UI Display:**
+
 | Test | Status |
 |------|--------|
 | Display challenge panel with required elements | ✅ Pass |
@@ -112,12 +128,14 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Display status indicator | ✅ Pass (Fixed) |
 
 **Copy to Clipboard:**
+
 | Test | Status |
 |------|--------|
 | Have accessible copy buttons | ✅ Pass |
 | Show copied feedback on click | ✅ Pass |
 
 **Verify Button Interactions:**
+
 | Test | Status |
 |------|--------|
 | Have Check DNS Now button | ✅ Pass |
@@ -125,6 +143,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Have Verify button with description | ✅ Pass |
 
 **Accessibility Checks:**
+
 | Test | Status |
 |------|--------|
 | Keyboard accessible interactive elements | ✅ Pass |
@@ -134,6 +153,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Validate accessibility tree structure | ✅ Pass (Fixed) |
 
 **Component Tests:**
+
 | Test | Status |
 |------|--------|
 | Render all required challenge information | ✅ Pass |
@@ -141,6 +161,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 | Handle verified challenge state | ✅ Pass |
 
 **Error Handling:**
+
 | Test | Status |
 |------|--------|
 | Display error message on verification failure | ✅ Pass |
@@ -149,6 +170,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 ## Issues Fixed
 
 ### 1. URL Path Mismatch
+
 **Issue**: `manual-dns-provider.spec.ts` used `/dns-providers` URL while the frontend uses `/dns/providers`.
 
 **Fix**: Updated all occurrences to use `/dns/providers`.
@@ -156,11 +178,13 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 **Files Changed**: `tests/manual-dns-provider.spec.ts`
 
 ### 2. Button Selector Too Strict
+
 **Issue**: Tests used `getByRole('button', { name: /add provider/i })` without `.first()` which failed when multiple buttons matched.
 
 **Fix**: Added `.first()` to handle both header button and empty state button.
 
 ### 3. Dropdown Search Filter Test
+
 **Issue**: Test tried to fill text into a combobox that doesn't support text input.
 
 **Fix**: Changed test to verify keyboard navigation works instead.
@@ -168,6 +192,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 **File**: `tests/dns-provider-types.spec.ts`
 
 ### 4. Dynamic Field Locators
+
 **Issue**: Tests used `getByLabel(/url/i)` but credential fields are rendered dynamically without proper labels.
 
 **Fix**: Changed to locate fields by label text followed by input structure.
@@ -175,6 +200,7 @@ Successfully triaged and fixed Playwright E2E tests for the DNS Provider feature
 **Files Changed**: `tests/dns-provider-types.spec.ts`
 
 ### 5. Conditional Status Icon Test
+
 **Issue**: Test expected SVG icon in status indicator but icon may not always be present.
 
 **Fix**: Made icon check conditional.
@@ -194,6 +220,7 @@ This is expected behavior — these tests only run when provider cards with edit
 ## Test Fixtures Created
 
 Created `tests/fixtures/dns-providers.ts` with:
+
 - Mock provider types (built-in and custom)
 - Mock provider data for different types
 - Mock API responses

docs/testing/e2e-test-writing-guide.md

@@ -42,6 +42,7 @@ await scriptPath.fill('/path/to/script.sh');
 ```
 
 **Error (Firefox/WebKit)**:
+
 ```
 TimeoutError: locator.fill: Timeout 5000ms exceeded.
 =========================== logs ===========================
@@ -78,12 +79,14 @@ await scriptPath.fill('/path/to/script.sh');
 ### When to Use `getFormFieldByLabel()`
 
 ✅ **Use when**:
+
 - Form fields have complex label structures (nested elements, icons, tooltips)
 - Tests fail in Firefox/WebKit but pass in Chromium
 - Label text is dynamic or internationalized
 - Multiple fields have similar labels
 
 ❌ **Don't use when**:
+
 - Standard `getByLabel()` works reliably across all browsers
 - Field has a unique `data-testid` or `name` attribute
 - Field is the only one of its type on the page
@@ -184,11 +187,13 @@ if (alreadyMatches(currentState, expectedFlags)) {
 ```
 
 **Cache Key Format**:
+
 ```
 [worker_index]:[sorted_flags_json]
 ```
 
 **Example**:
+
 ```
 Worker 0: "0:{\"feature.cerberus.enabled\":false,\"feature.crowdsec.enabled\":false}"
 Worker 1: "1:{\"feature.cerberus.enabled\":false,\"feature.crowdsec.enabled\":false}"
@@ -201,11 +206,13 @@ Worker 1: "1:{\"feature.cerberus.enabled\":false,\"feature.crowdsec.enabled\":fa
 ### When to Use `waitForFeatureFlagPropagation()`
 
 ✅ **Use when**:
+
 - A test **toggles** a feature flag via the UI
 - Backend state changes and you need to verify propagation
 - Test depends on a specific flag state being active
 
 ❌ **Don't use when**:
+
 - Setting up initial state in `beforeEach` (use API directly instead)
 - Flags haven't changed since last verification
 - Test doesn't modify flags
@@ -239,6 +246,7 @@ test.describe('System Settings', () => {
 ```
 
 **Why This Works**:
+
 - Each test starts from known defaults (restored by previous test's `afterEach`)
 - No unnecessary polling in `beforeEach`
 - Cleanup happens once, not N times per describe block
@@ -261,6 +269,7 @@ export async function waitForFeatureFlagPropagation(...) {
 ```
 
 **You don't need to manually wait for the overlay** — it's handled by:
+
 - `clickSwitch()`
 - `clickAndWaitForResponse()`
 - `waitForFeatureFlagPropagation()`
@@ -272,6 +281,7 @@ export async function waitForFeatureFlagPropagation(...) {
 ### Why Isolation Matters
 
 Tests running in parallel can interfere with each other if they:
+
 - Share mutable state (database, config files, feature flags)
 - Don't clean up resources
 - Rely on global defaults
@@ -423,11 +433,13 @@ await field.fill('value');
 **Symptom**: `Feature flag propagation timeout after 120 attempts (60000ms)`
 
 **Causes**:
+
 1. Backend not updating flags
 2. Config reload overlay blocking UI
 3. Database transaction not committed
 
 **Fix Steps**:
+
 1. Check backend logs: Does PUT `/api/v1/feature-flags` succeed?
 2. Check overlay state: Is `[data-testid="config-reload-overlay"]` stuck visible?
 3. Increase timeout temporarily: `waitForFeatureFlagPropagation(page, flags, { timeout: 120000 })`
@@ -499,6 +511,7 @@ test.afterEach(async ({ request }) => {
 ---
 
 **See Also**:
+
 - [Testing README](./README.md) — Quick reference and debugging guide
 - [Switch Component Testing](./README.md#-switchtoggle-component-testing) — Detailed switch patterns
 - [Debugging Guide](./debugging-guide.md) — Troubleshooting slow/flaky tests

docs/testing/sprint1-improvements.md

@@ -11,11 +11,13 @@ During Sprint 1, we resolved critical issues affecting E2E test reliability and
 **What was happening**: Some tests would hang indefinitely or timeout after 30 seconds, especially in CI/CD pipelines.
 
 **Root cause**:
+
 - Config reload overlay was blocking test interactions
 - Feature flag propagation was too slow during high load
 - API polling happened unnecessarily for every test
 
 **What we did**:
+
 1. Added smart detection to wait for config reloads to complete
 2. Increased timeouts to accommodate slower environments
 3. Implemented request caching to reduce redundant API calls

docs/troubleshooting/e2e-tests.md

@@ -11,11 +11,13 @@ Common issues and solutions for Playwright E2E tests.
 **Symptoms**: Tests timing out after 30 seconds, config reload overlay blocking interactions
 
 **Resolution**:
+
 - Extended timeout from 30s to 60s for feature flag propagation
 - Added automatic detection and waiting for config reload overlay
 - Improved test isolation with proper cleanup in afterEach hooks
 
 **If you still experience timeouts**:
+
 1. Rebuild the E2E container: `.github/skills/scripts/skill-runner.sh docker-rebuild-e2e`
 2. Check Docker logs for health check failures
 3. Verify emergency token is set in `.env` file
@@ -25,6 +27,7 @@ Common issues and solutions for Playwright E2E tests.
 **Symptoms**: Feature flag tests failing with propagation timeout
 
 **Resolution**:
+
 - Added key normalization to handle both `feature.cerberus.enabled` and `cerberus.enabled` formats
 - Tests now automatically detect and adapt to API response format
 
@@ -67,21 +70,25 @@ Emergency token not configured in `.env` file.
 ### Solution
 
 1. **Generate token:**
+
    ```bash
    openssl rand -hex 32
    ```
 
 2. **Add to `.env` file:**
+
    ```bash
    echo "CHARON_EMERGENCY_TOKEN=<paste_token_here>" >> .env
    ```
 
 3. **Verify:**
+
    ```bash
    grep CHARON_EMERGENCY_TOKEN .env
    ```
 
 4. **Run tests:**
+
    ```bash
    npx playwright test --project=chromium
    ```
@@ -104,16 +111,19 @@ Token is shorter than 64 characters (security requirement).
 ### Solution
 
 1. **Regenerate token with correct length:**
+
    ```bash
    openssl rand -hex 32  # Generates 64-char hex string
    ```
 
 2. **Update `.env` file:**
+
    ```bash
    sed -i "s/CHARON_EMERGENCY_TOKEN=.*/CHARON_EMERGENCY_TOKEN=<new_token>/" .env
    ```
 
 3. **Verify length:**
+
    ```bash
    echo -n "$(grep CHARON_EMERGENCY_TOKEN .env | cut -d= -f2)" | wc -c
    # Should output: 64
@@ -139,6 +149,7 @@ Token is shorter than 64 characters (security requirement).
 ### Solution
 
 **Step 1: Verify token configuration**
+
 ```bash
 # Check token exists and is 64 chars
 echo -n "$(grep CHARON_EMERGENCY_TOKEN .env | cut -d= -f2)" | wc -c
@@ -148,12 +159,14 @@ docker exec charon env | grep CHARON_EMERGENCY_TOKEN
 ```
 
 **Step 2: Verify backend is running**
+
 ```bash
 curl http://localhost:8080/api/v1/health
 # Should return: {"status":"ok"}
 ```
 
 **Step 3: Test emergency endpoint directly**
+
 ```bash
 curl -X POST http://localhost:8080/api/v1/emergency/security-reset \
   -H "X-Emergency-Token: $(grep CHARON_EMERGENCY_TOKEN .env | cut -d= -f2)" \
@@ -162,6 +175,7 @@ curl -X POST http://localhost:8080/api/v1/emergency/security-reset \
 ```
 
 **Step 4: Check backend logs**
+
 ```bash
 # Docker Compose
 docker compose logs charon | tail -50
@@ -171,6 +185,7 @@ docker logs charon | tail -50
 ```
 
 **Step 5: Regenerate token if needed**
+
 ```bash
 # Generate new token
 NEW_TOKEN=$(openssl rand -hex 32)
@@ -201,6 +216,7 @@ Security teardown did not successfully disable ACL before tests ran.
 ### Solution
 
 1. **Run teardown script manually:**
+
    ```bash
    npx playwright test tests/security-teardown.setup.ts
    ```
@@ -210,12 +226,14 @@ Security teardown did not successfully disable ACL before tests ran.
    - Verify no error messages about missing token
 
 3. **Verify ACL is disabled:**
+
    ```bash
    curl http://localhost:8080/api/v1/security/status | jq
    # acl.enabled should be false
    ```
 
 4. **If still blocked, manually disable via API:**
+
    ```bash
    # Using emergency token
    curl -X POST http://localhost:8080/api/v1/emergency/security-reset \
@@ -225,6 +243,7 @@ Security teardown did not successfully disable ACL before tests ran.
    ```
 
 5. **Run tests again:**
+
    ```bash
    npx playwright test --project=chromium
    ```
@@ -282,11 +301,13 @@ Backend container not running or not accessible.
 ### Solution
 
 1. **Check container status:**
+
    ```bash
    docker ps | grep charon
    ```
 
 2. **If not running, start it:**
+
    ```bash
    # Docker Compose
    docker compose up -d
@@ -296,11 +317,13 @@ Backend container not running or not accessible.
    ```
 
 3. **Wait for health:**
+
    ```bash
    timeout 60 bash -c 'until curl -f http://localhost:8080/api/v1/health; do sleep 2; done'
    ```
 
 4. **Check logs if still failing:**
+
    ```bash
    docker logs charon | tail -50
    ```
@@ -317,6 +340,7 @@ Backend container not running or not accessible.
 ### Cause
 
 Token contains common placeholder strings like:
+
 - `test-emergency-token`
 - `your_64_character`
 - `replace_this`
@@ -325,16 +349,19 @@ Token contains common placeholder strings like:
 ### Solution
 
 1. **Generate a unique token:**
+
    ```bash
    openssl rand -hex 32
    ```
 
 2. **Replace placeholder in `.env`:**
+
    ```bash
    sed -i "s/CHARON_EMERGENCY_TOKEN=.*/CHARON_EMERGENCY_TOKEN=<new_token>/" .env
    ```
 
 3. **Verify it's not a placeholder:**
+
    ```bash
    grep CHARON_EMERGENCY_TOKEN .env
    # Should show a random hex string
@@ -389,16 +416,19 @@ Enables all debug output.
 **Solutions:**
 
 1. **Use sharding (parallel execution):**
+
    ```bash
    npx playwright test --shard=1/4 --project=chromium
    ```
 
 2. **Run specific test files:**
+
    ```bash
    npx playwright test tests/manual-dns-provider.spec.ts
    ```
 
 3. **Skip slow tests during development:**
+
    ```bash
    npx playwright test --grep-invert "@slow"
    ```
@@ -406,19 +436,23 @@ Enables all debug output.
 ### Feature Flag Toggle Tests Timing Out
 
 **Symptoms:**
+
 - Tests in `tests/settings/system-settings.spec.ts` fail with timeout errors
 - Error messages mention feature flag toggles (Cerberus, CrowdSec, Uptime, Persist)
 
 **Cause:**
+
 - Backend N+1 query pattern causing 300-600ms latency in CI
 - Hard-coded waits insufficient for slower CI environments
 
 **Solution (Fixed in v2.x):**
+
 - Backend now uses batch query pattern (3-6x faster: 600ms → 200ms P99)
 - Tests use condition-based polling with `waitForFeatureFlagPropagation()`
 - Retry logic with exponential backoff handles transient failures
 
 **If you still experience issues:**
+
 1. Check backend latency: `grep "[METRICS]" docker logs charon`
 2. Verify batch query is being used (should see `WHERE key IN (...)` in logs)
 3. Ensure you're running latest version with the optimization
@@ -432,16 +466,19 @@ Enables all debug output.
 **Solutions:**
 
 1. **Increase health check timeout:**
+
    ```bash
    timeout 120 bash -c 'until curl -f http://localhost:8080/api/v1/health; do sleep 2; done'
    ```
 
 2. **Pre-pull Docker image:**
+
    ```bash
    docker pull wikid82/charon:latest
    ```
 
 3. **Check Docker resource limits:**
+
    ```bash
    docker stats charon
    # Ensure adequate CPU/memory
@@ -458,6 +495,7 @@ If you're still stuck after trying these solutions:
    - Search [GitHub Issues](https://github.com/Wikid82/charon/issues)
 
 2. **Collect diagnostic info:**
+
    ```bash
    # Environment
    echo "OS: $(uname -a)"

frontend/package.json

@@ -33,20 +33,20 @@
     "@radix-ui/react-select": "^2.2.6",
     "@radix-ui/react-tabs": "^1.1.13",
     "@radix-ui/react-tooltip": "^1.2.8",
-    "@tanstack/react-query": "^5.91.3",
+    "@tanstack/react-query": "^5.95.2",
     "axios": "^1.13.6",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",
     "date-fns": "^4.1.0",
-    "i18next": "^25.9.0",
+    "i18next": "^25.10.9",
     "i18next-browser-languagedetector": "^8.2.1",
-    "lucide-react": "^0.577.0",
+    "lucide-react": "^1.6.0",
     "react": "^19.2.4",
     "react-dom": "^19.2.4",
-    "react-hook-form": "^7.71.2",
+    "react-hook-form": "^7.72.0",
     "react-hot-toast": "^2.6.0",
-    "react-i18next": "^16.5.8",
-    "react-router-dom": "^7.13.1",
+    "react-i18next": "^16.6.6",
+    "react-router-dom": "^7.13.2",
     "tailwind-merge": "^3.5.0",
     "tldts": "^7.0.27"
   },
@@ -64,14 +64,14 @@
     "@types/node": "^25.5.0",
     "@types/react": "^19.2.14",
     "@types/react-dom": "^19.2.3",
-    "@typescript-eslint/eslint-plugin": "^8.57.1",
-    "@typescript-eslint/parser": "^8.57.1",
-    "@typescript-eslint/utils": "^8.57.1",
+    "@typescript-eslint/eslint-plugin": "^8.57.2",
+    "@typescript-eslint/parser": "^8.57.2",
+    "@typescript-eslint/utils": "^8.57.2",
     "@vitejs/plugin-react": "^6.0.1",
-    "@vitest/coverage-istanbul": "^4.1.0",
-    "@vitest/coverage-v8": "^4.1.0",
-    "@vitest/eslint-plugin": "^1.6.12",
-    "@vitest/ui": "^4.1.0",
+    "@vitest/coverage-istanbul": "^4.1.1",
+    "@vitest/coverage-v8": "^4.1.1",
+    "@vitest/eslint-plugin": "^1.6.13",
+    "@vitest/ui": "^4.1.1",
     "autoprefixer": "^10.4.27",
     "eslint": "^10.1.0",
     "eslint-import-resolver-typescript": "^4.4.4",
@@ -84,21 +84,21 @@
     "eslint-plugin-react-refresh": "^0.5.2",
     "eslint-plugin-security": "^4.0.0",
     "eslint-plugin-sonarjs": "^4.0.2",
-    "eslint-plugin-testing-library": "^7.16.1",
+    "eslint-plugin-testing-library": "^7.16.2",
     "eslint-plugin-unicorn": "^63.0.0",
     "eslint-plugin-unused-imports": "^4.4.1",
     "jsdom": "29.0.1",
-    "knip": "^6.0.1",
+    "knip": "^6.0.4",
     "postcss": "^8.5.8",
     "tailwindcss": "^4.2.2",
-    "typescript": "^6.0.1-rc",
-    "typescript-eslint": "^8.57.1",
-    "vite": "^8.0.1",
-    "vitest": "^4.1.0",
+    "typescript": "^6.0.2",
+    "typescript-eslint": "^8.57.2",
+    "vite": "^8.0.2",
+    "vitest": "^4.1.1",
     "zod-validation-error": "^5.0.0"
   },
   "overrides": {
-    "typescript": "^6.0.1-rc",
+    "typescript": "^6.0.2",
     "eslint-plugin-react-hooks": {
       "eslint": "^10.1.0"
     },
@@ -109,7 +109,7 @@
       "eslint": "^10.1.0"
     },
     "@vitejs/plugin-react": {
-      "vite": "8.0.1"
+      "vite": "8.0.2"
     }
   }
 }

frontend/src/api/notifications.ts

@@ -1,6 +1,6 @@
 import client from './client';
 
-export const SUPPORTED_NOTIFICATION_PROVIDER_TYPES = ['discord', 'gotify', 'webhook', 'email', 'telegram', 'slack', 'pushover'] as const;
+export const SUPPORTED_NOTIFICATION_PROVIDER_TYPES = ['discord', 'gotify', 'webhook', 'email', 'telegram', 'slack', 'pushover', 'ntfy'] as const;
 export type SupportedNotificationProviderType = (typeof SUPPORTED_NOTIFICATION_PROVIDER_TYPES)[number];
 const DEFAULT_PROVIDER_TYPE: SupportedNotificationProviderType = 'discord';
 
@@ -59,7 +59,7 @@ const sanitizeProviderForWriteAction = (data: Partial<NotificationProvider>): Pa
 
   delete payload.gotify_token;
 
-  if (type !== 'gotify' && type !== 'telegram' && type !== 'slack' && type !== 'pushover') {
+  if (type !== 'gotify' && type !== 'telegram' && type !== 'slack' && type !== 'pushover' && type !== 'ntfy') {
     delete payload.token;
     return payload;
   }

frontend/src/components/CertificateList.tsx

@@ -1,37 +1,97 @@
 import { useMutation, useQueryClient } from '@tanstack/react-query'
 import { Trash2, ChevronUp, ChevronDown } from 'lucide-react'
-import { useState, useMemo } from 'react'
+import { useState, useMemo, useEffect } from 'react'
+import { useTranslation } from 'react-i18next'
 
+import BulkDeleteCertificateDialog from './dialogs/BulkDeleteCertificateDialog'
+import DeleteCertificateDialog from './dialogs/DeleteCertificateDialog'
 import { LoadingSpinner, ConfigReloadOverlay } from './LoadingStates'
-import { createBackup } from '../api/backups'
-import { deleteCertificate } from '../api/certificates'
+import { Button } from './ui/Button'
+import { Checkbox } from './ui/Checkbox'
+import { Tooltip, TooltipContent, TooltipProvider, TooltipTrigger } from './ui/Tooltip'
+import { deleteCertificate, type Certificate } from '../api/certificates'
 import { useCertificates } from '../hooks/useCertificates'
 import { useProxyHosts } from '../hooks/useProxyHosts'
 import { toast } from '../utils/toast'
 
+import type { ProxyHost } from '../api/proxyHosts'
+
 type SortColumn = 'name' | 'expires'
 type SortDirection = 'asc' | 'desc'
 
+export function isInUse(cert: Certificate, hosts: ProxyHost[]): boolean {
+  if (!cert.id) return false
+  return hosts.some(h => (h.certificate_id ?? h.certificate?.id) === cert.id)
+}
+
+export function isDeletable(cert: Certificate, hosts: ProxyHost[]): boolean {
+  if (!cert.id) return false
+  if (isInUse(cert, hosts)) return false
+  return (
+    cert.provider === 'custom' ||
+    cert.provider === 'letsencrypt-staging' ||
+    cert.status === 'expired' ||
+    cert.status === 'expiring'
+  )
+}
+
 export default function CertificateList() {
   const { certificates, isLoading, error } = useCertificates()
   const { hosts } = useProxyHosts()
   const queryClient = useQueryClient()
+  const { t } = useTranslation()
   const [sortColumn, setSortColumn] = useState<SortColumn>('name')
   const [sortDirection, setSortDirection] = useState<SortDirection>('asc')
+  const [certToDelete, setCertToDelete] = useState<Certificate | null>(null)
+  const [selectedIds, setSelectedIds] = useState<Set<number>>(new Set())
+  const [showBulkDeleteDialog, setShowBulkDeleteDialog] = useState(false)
+
+  useEffect(() => {
+    setSelectedIds(prev => {
+      const validIds = new Set(certificates.map(c => c.id).filter((id): id is number => id != null))
+      const reconciled = new Set([...prev].filter(id => validIds.has(id)))
+      if (reconciled.size === prev.size) return prev
+      return reconciled
+    })
+  }, [certificates])
 
   const deleteMutation = useMutation({
-    // Perform backup before actual deletion
     mutationFn: async (id: number) => {
-      await createBackup()
       await deleteCertificate(id)
     },
     onSuccess: () => {
       queryClient.invalidateQueries({ queryKey: ['certificates'] })
       queryClient.invalidateQueries({ queryKey: ['proxyHosts'] })
-      toast.success('Certificate deleted')
+      toast.success(t('certificates.deleteSuccess'))
+      setCertToDelete(null)
     },
     onError: (error: Error) => {
-      toast.error(`Failed to delete certificate: ${error.message}`)
+      toast.error(`${t('certificates.deleteFailed')}: ${error.message}`)
+      setCertToDelete(null)
+    },
+  })
+
+  const bulkDeleteMutation = useMutation({
+    mutationFn: async (ids: number[]) => {
+      const results = await Promise.allSettled(ids.map(id => deleteCertificate(id)))
+      const failed = results.filter(r => r.status === 'rejected').length
+      const succeeded = results.filter(r => r.status === 'fulfilled').length
+      return { succeeded, failed }
+    },
+    onSuccess: ({ succeeded, failed }) => {
+      queryClient.invalidateQueries({ queryKey: ['certificates'] })
+      queryClient.invalidateQueries({ queryKey: ['proxyHosts'] })
+      setSelectedIds(new Set())
+      setShowBulkDeleteDialog(false)
+      if (failed > 0) {
+        toast.error(t('certificates.bulkDeletePartial', { deleted: succeeded, failed }))
+      } else {
+        toast.success(t('certificates.bulkDeleteSuccess', { count: succeeded }))
+      }
+    },
+    onError: () => {
+      toast.error(t('certificates.bulkDeleteFailed'))
+      setShowBulkDeleteDialog(false)
     },
   })
 
@@ -58,6 +118,39 @@ export default function CertificateList() {
     })
   }, [certificates, sortColumn, sortDirection])
 
+  const selectableCertIds = useMemo<Set<number>>(() => {
+    const ids = new Set<number>()
+    for (const cert of sortedCertificates) {
+      if (isDeletable(cert, hosts) && cert.id) {
+        ids.add(cert.id)
+      }
+    }
+    return ids
+  }, [sortedCertificates, hosts])
+
+  const allSelectableSelected =
+    selectableCertIds.size > 0 && selectedIds.size === selectableCertIds.size
+  const someSelected =
+    selectedIds.size > 0 && selectedIds.size < selectableCertIds.size
+
+  const handleSelectAll = () => {
+    if (selectedIds.size === selectableCertIds.size) {
+      setSelectedIds(new Set())
+    } else {
+      setSelectedIds(new Set(selectableCertIds))
+    }
+  }
+
+  const handleSelectRow = (id: number) => {
+    const next = new Set(selectedIds)
+    if (next.has(id)) {
+      next.delete(id)
+    } else {
+      next.add(id)
+    }
+    setSelectedIds(next)
+  }
+
   const handleSort = (column: SortColumn) => {
     if (sortColumn === column) {
       setSortDirection(prev => prev === 'asc' ? 'desc' : 'asc')
@@ -77,18 +170,46 @@ export default function CertificateList() {
 
   return (
     <>
-      {deleteMutation.isPending && (
+      {(deleteMutation.isPending || bulkDeleteMutation.isPending) && (
         <ConfigReloadOverlay
           message="Returning to shore..."
           submessage="Certificate departure in progress"
           type="charon"
         />
       )}
+      {selectedIds.size > 0 && (
+        <div
+          role="status"
+          aria-live="polite"
+          className="flex items-center justify-between rounded-lg border border-brand-500/30 bg-brand-500/10 px-4 py-2 mb-3"
+        >
+          <span className="text-sm text-gray-300">
+            {t('certificates.bulkSelectedCount', { count: selectedIds.size })}
+          </span>
+          <Button
+            variant="danger"
+            size="sm"
+            leftIcon={Trash2}
+            onClick={() => setShowBulkDeleteDialog(true)}
+          >
+            {t('certificates.bulkDeleteButton', { count: selectedIds.size })}
+          </Button>
+        </div>
+      )}
       <div className="bg-dark-card rounded-lg border border-gray-800 overflow-hidden">
       <div className="overflow-x-auto">
         <table className="w-full text-left text-sm text-gray-400">
           <thead className="bg-gray-900 text-gray-200 uppercase font-medium">
             <tr>
+              <th className="w-12 px-4 py-3">
+                <Checkbox
+                  checked={allSelectableSelected}
+                  indeterminate={someSelected}
+                  onCheckedChange={handleSelectAll}
+                  aria-label={t('certificates.bulkSelectAll')}
+                  disabled={selectableCertIds.size === 0}
+                />
+              </th>
               <th
                 onClick={() => handleSort('name')}
                 className="px-6 py-3 cursor-pointer hover:text-white transition-colors"
@@ -116,13 +237,47 @@ export default function CertificateList() {
           <tbody className="divide-y divide-gray-800">
             {certificates.length === 0 ? (
               <tr>
-                <td colSpan={6} className="px-6 py-8 text-center text-gray-500">
+                <td colSpan={7} className="px-6 py-8 text-center text-gray-500">
                   No certificates found.
                 </td>
               </tr>
             ) : (
-              sortedCertificates.map((cert) => (
+              sortedCertificates.map((cert) => {
+                const inUse = isInUse(cert, hosts)
+                const deletable = isDeletable(cert, hosts)
+                const isInUseDeletableCategory = inUse && (cert.provider === 'custom' || cert.provider === 'letsencrypt-staging' || cert.status === 'expired' || cert.status === 'expiring')
+
+                return (
                 <tr key={cert.id || cert.domain} className="hover:bg-gray-800/50 transition-colors">
+                  {deletable && !inUse ? (
+                    <td className="w-12 px-4 py-4">
+                      <Checkbox
+                        checked={selectedIds.has(cert.id!)}
+                        onCheckedChange={() => handleSelectRow(cert.id!)}
+                        aria-label={t('certificates.selectCert', { name: cert.name || cert.domain })}
+                      />
+                    </td>
+                  ) : isInUseDeletableCategory ? (
+                    <td className="w-12 px-4 py-4">
+                      <TooltipProvider>
+                        <Tooltip>
+                          <TooltipTrigger asChild>
+                            <span className="inline-flex">
+                              <Checkbox
+                                checked={false}
+                                disabled
+                                aria-disabled="true"
+                                aria-label={t('certificates.selectCert', { name: cert.name || cert.domain })}
+                              />
+                            </span>
+                          </TooltipTrigger>
+                          <TooltipContent>{t('certificates.deleteInUse')}</TooltipContent>
+                        </Tooltip>
+                      </TooltipProvider>
+                    </td>
+                  ) : (
+                    <td className="w-12 px-4 py-4" aria-hidden="true" />
+                  )}
                   <td className="px-6 py-4 font-medium text-white">{cert.name || '-'}</td>
                   <td className="px-6 py-4 font-medium text-white">{cert.domain}</td>
                   <td className="px-6 py-4">
@@ -142,42 +297,70 @@ export default function CertificateList() {
                     <StatusBadge status={cert.status} />
                   </td>
                   <td className="px-6 py-4">
-                    {cert.id && (cert.provider === 'custom' || cert.issuer?.toLowerCase().includes('staging')) && (
-                      <button
-                        onClick={() => {
-                          // Determine if certificate is in use by any proxy host
-                          const inUse = hosts.some(h => {
-                            const cid = h.certificate_id ?? h.certificate?.id
-                            return cid === cert.id
-                          })
+                    {(() => {
+                      if (cert.id && inUse && (cert.provider === 'custom' || cert.provider === 'letsencrypt-staging' || cert.status === 'expired')) {
+                        return (
+                          <TooltipProvider>
+                            <Tooltip>
+                              <TooltipTrigger asChild>
+                                <button
+                                  aria-disabled="true"
+                                  aria-label={t('certificates.deleteTitle')}
+                                  className="text-red-400/40 cursor-not-allowed transition-colors"
+                                  onClick={(e) => e.preventDefault()}
+                                >
+                                  <Trash2 className="w-4 h-4" />
+                                </button>
+                              </TooltipTrigger>
+                              <TooltipContent>
+                                {t('certificates.deleteInUse')}
+                              </TooltipContent>
+                            </Tooltip>
+                          </TooltipProvider>
+                        )
+                      }
 
-                          if (inUse) {
-                            toast.error('Certificate cannot be deleted because it is in use by a proxy host')
-                            return
-                          }
+                      if (deletable) {
+                        return (
+                          <button
+                            onClick={() => setCertToDelete(cert)}
+                            className="text-red-400 hover:text-red-300 transition-colors"
+                            aria-label={t('certificates.deleteTitle')}
+                          >
+                            <Trash2 className="w-4 h-4" />
+                          </button>
+                        )
+                      }
 
-                          // Allow deletion for custom/staging certs not in use (status check removed)
-                          const message = cert.provider === 'custom'
-                            ? 'Are you sure you want to delete this certificate? This will create a backup before deleting.'
-                            : 'Delete this staging certificate? It will be regenerated on next request.'
-                          if (confirm(message)) {
-                            deleteMutation.mutate(cert.id!)
-                          }
-                        }}
-                        className="text-red-400 hover:text-red-300 transition-colors"
-                        title={cert.provider === 'custom' ? 'Delete Certificate' : 'Delete Staging Certificate'}
-                      >
-                        <Trash2 className="w-4 h-4" />
-                      </button>
-                    )}
+                      return null
+                    })()}
                   </td>
                 </tr>
-              ))
+                )
+              })
             )}
           </tbody>
         </table>
       </div>
       </div>
+      <DeleteCertificateDialog
+        certificate={certToDelete}
+        open={certToDelete !== null}
+        onConfirm={() => {
+          if (certToDelete?.id) {
+            deleteMutation.mutate(certToDelete.id)
+          }
+        }}
+        onCancel={() => setCertToDelete(null)}
+        isDeleting={deleteMutation.isPending}
+      />
+      <BulkDeleteCertificateDialog
+        certificates={sortedCertificates.filter(c => c.id && selectedIds.has(c.id))}
+        open={showBulkDeleteDialog}
+        onConfirm={() => bulkDeleteMutation.mutate(Array.from(selectedIds))}
+        onCancel={() => setShowBulkDeleteDialog(false)}
+        isDeleting={bulkDeleteMutation.isPending}
+      />
     </>
   )
 }

frontend/src/components/__tests__/CertificateList.test.tsx

@@ -1,12 +1,12 @@
 import { QueryClientProvider } from '@tanstack/react-query'
-import { render, screen, waitFor } from '@testing-library/react'
+import { render, screen, waitFor, within } from '@testing-library/react'
 import userEvent from '@testing-library/user-event'
 import { describe, it, expect, vi, beforeEach } from 'vitest'
 
 import { useCertificates } from '../../hooks/useCertificates'
 import { useProxyHosts } from '../../hooks/useProxyHosts'
 import { createTestQueryClient } from '../../test/createTestQueryClient'
-import CertificateList from '../CertificateList'
+import CertificateList, { isDeletable, isInUse } from '../CertificateList'
 
 import type { Certificate } from '../../api/certificates'
 import type { ProxyHost } from '../../api/proxyHosts'
@@ -23,6 +23,13 @@ vi.mock('../../api/backups', () => ({
   createBackup: vi.fn(async () => ({ filename: 'backup-cert' })),
 }))
 
+vi.mock('react-i18next', () => ({
+  useTranslation: () => ({
+    t: (key: string) => key,
+    i18n: { language: 'en', changeLanguage: vi.fn() },
+  }),
+}))
+
 vi.mock('../../hooks/useProxyHosts', () => ({
   useProxyHosts: vi.fn(),
 }))
@@ -42,6 +49,8 @@ const createCertificatesValue = (overrides: Partial<ReturnType<typeof useCertifi
     { id: 2, name: 'LE Staging', domain: 'staging.example.com', issuer: "Let's Encrypt Staging", expires_at: '2026-04-01T00:00:00Z', status: 'untrusted', provider: 'letsencrypt-staging' },
     { id: 3, name: 'ActiveCert', domain: 'active.example.com', issuer: 'Custom CA', expires_at: '2026-02-01T00:00:00Z', status: 'valid', provider: 'custom' },
     { id: 4, name: 'UnusedValidCert', domain: 'unused.example.com', issuer: 'Custom CA', expires_at: '2026-05-01T00:00:00Z', status: 'valid', provider: 'custom' },
+    { id: 5, name: 'ExpiredLE', domain: 'expired-le.example.com', issuer: "Let's Encrypt", expires_at: '2025-01-01T00:00:00Z', status: 'expired', provider: 'letsencrypt' },
+    { id: 6, name: 'ValidLE', domain: 'valid-le.example.com', issuer: "Let's Encrypt", expires_at: '2026-12-01T00:00:00Z', status: 'valid', provider: 'letsencrypt' },
   ]
 
   return {
@@ -98,7 +107,7 @@ const getRowNames = () =>
   screen
     .getAllByRole('row')
     .slice(1)
-    .map(row => row.querySelector('td')?.textContent?.trim() ?? '')
+    .map(row => row.querySelectorAll('td')[1]?.textContent?.trim() ?? '')
 
 beforeEach(() => {
   vi.clearAllMocks()
@@ -107,58 +116,133 @@ beforeEach(() => {
 })
 
 describe('CertificateList', () => {
-  it('deletes custom certificate when confirmed', async () => {
-    const confirmSpy = vi.spyOn(window, 'confirm').mockImplementation(() => true)
+  describe('isDeletable', () => {
+    const noHosts: ProxyHost[] = []
+    const withHost = (certId: number): ProxyHost[] => [createProxyHost({ certificate_id: certId })]
+
+    it('returns true for custom cert not in use', () => {
+      const cert: Certificate = { id: 1, name: 'C', domain: 'd', issuer: 'X', expires_at: '', status: 'valid', provider: 'custom' }
+      expect(isDeletable(cert, noHosts)).toBe(true)
+    })
+
+    it('returns true for staging cert not in use', () => {
+      const cert: Certificate = { id: 2, name: 'S', domain: 'd', issuer: 'X', expires_at: '', status: 'untrusted', provider: 'letsencrypt-staging' }
+      expect(isDeletable(cert, noHosts)).toBe(true)
+    })
+
+    it('returns true for expired LE cert not in use', () => {
+      const cert: Certificate = { id: 3, name: 'E', domain: 'd', issuer: 'LE', expires_at: '', status: 'expired', provider: 'letsencrypt' }
+      expect(isDeletable(cert, noHosts)).toBe(true)
+    })
+
+    it('returns false for valid LE cert not in use', () => {
+      const cert: Certificate = { id: 4, name: 'V', domain: 'd', issuer: 'LE', expires_at: '', status: 'valid', provider: 'letsencrypt' }
+      expect(isDeletable(cert, noHosts)).toBe(false)
+    })
+
+    it('returns false for cert in use', () => {
+      const cert: Certificate = { id: 5, name: 'U', domain: 'd', issuer: 'X', expires_at: '', status: 'valid', provider: 'custom' }
+      expect(isDeletable(cert, withHost(5))).toBe(false)
+    })
+
+    it('returns false for cert without id', () => {
+      const cert: Certificate = { domain: 'd', issuer: 'X', expires_at: '', status: 'valid', provider: 'custom' }
+      expect(isDeletable(cert, noHosts)).toBe(false)
+    })
+
+    it('returns true for expiring LE cert not in use', () => {
+      const cert: Certificate = { id: 7, name: 'Exp', domain: 'd', issuer: 'LE', expires_at: '', status: 'expiring', provider: 'letsencrypt' }
+      expect(isDeletable(cert, noHosts)).toBe(true)
+    })
+
+    it('returns false for expiring LE cert that is in use', () => {
+      const cert: Certificate = { id: 7, name: 'Exp', domain: 'd', issuer: 'LE', expires_at: '', status: 'expiring', provider: 'letsencrypt' }
+      expect(isDeletable(cert, withHost(7))).toBe(false)
+    })
+  })
+
+  describe('isInUse', () => {
+    it('returns true when host references cert by certificate_id', () => {
+      const cert: Certificate = { id: 10, domain: 'd', issuer: 'X', expires_at: '', status: 'valid', provider: 'custom' }
+      expect(isInUse(cert, [createProxyHost({ certificate_id: 10 })])).toBe(true)
+    })
+
+    it('returns true when host references cert via certificate.id', () => {
+      const cert: Certificate = { id: 10, domain: 'd', issuer: 'X', expires_at: '', status: 'valid', provider: 'custom' }
+      const host = createProxyHost({ certificate_id: undefined, certificate: { id: 10, uuid: 'u', name: 'c', provider: 'custom', domains: 'd', expires_at: '' } })
+      expect(isInUse(cert, [host])).toBe(true)
+    })
+
+    it('returns false when no host references cert', () => {
+      const cert: Certificate = { id: 99, domain: 'd', issuer: 'X', expires_at: '', status: 'valid', provider: 'custom' }
+      expect(isInUse(cert, [createProxyHost({ certificate_id: 3 })])).toBe(false)
+    })
+
+    it('returns false when cert.id is undefined even if a host has certificate_id undefined', () => {
+      const cert: Certificate = { domain: 'd', issuer: 'X', expires_at: '', status: 'valid', provider: 'custom' }
+      const host = createProxyHost({ certificate_id: undefined })
+      expect(isInUse(cert, [host])).toBe(false)
+    })
+  })
+
+  it('renders delete button for deletable certs', async () => {
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const customRow = rows.find(r => r.textContent?.includes('CustomCert'))!
+    expect(within(customRow).getByRole('button', { name: 'certificates.deleteTitle' })).toBeInTheDocument()
+  })
+
+  it('renders delete button for expired LE cert not in use', async () => {
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const expiredLeRow = rows.find(r => r.textContent?.includes('ExpiredLE'))!
+    expect(within(expiredLeRow).getByRole('button', { name: 'certificates.deleteTitle' })).toBeInTheDocument()
+  })
+
+  it('renders aria-disabled delete button for in-use cert', async () => {
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const activeRow = rows.find(r => r.textContent?.includes('ActiveCert'))!
+    const btn = within(activeRow).getByRole('button', { name: 'certificates.deleteTitle' })
+    expect(btn).toHaveAttribute('aria-disabled', 'true')
+  })
+
+  it('hides delete button for valid production LE cert', async () => {
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const validLeRow = rows.find(r => r.textContent?.includes('ValidLE'))!
+    expect(within(validLeRow).queryByRole('button', { name: 'certificates.deleteTitle' })).not.toBeInTheDocument()
+  })
+
+  it('opens dialog and deletes cert on confirm', async () => {
     const { deleteCertificate } = await import('../../api/certificates')
-    const { createBackup } = await import('../../api/backups')
-    const { toast } = await import('../../utils/toast')
     const user = userEvent.setup()
 
     renderWithClient(<CertificateList />)
     const rows = await screen.findAllByRole('row')
-    const customRow = rows.find(r => r.querySelector('td')?.textContent?.includes('CustomCert')) as HTMLElement
-    expect(customRow).toBeTruthy()
-    const customBtn = customRow.querySelector('button[title="Delete Certificate"]') as HTMLButtonElement
-    expect(customBtn).toBeTruthy()
-    await user.click(customBtn)
+    const customRow = rows.find(r => r.textContent?.includes('CustomCert'))!
+    await user.click(within(customRow).getByRole('button', { name: 'certificates.deleteTitle' }))
 
-    await waitFor(() => expect(createBackup).toHaveBeenCalled())
+    const dialog = await screen.findByRole('dialog')
+    expect(dialog).toBeInTheDocument()
+    expect(within(dialog).getByText('certificates.deleteTitle')).toBeInTheDocument()
+
+    await user.click(within(dialog).getByRole('button', { name: 'certificates.deleteButton' }))
     await waitFor(() => expect(deleteCertificate).toHaveBeenCalledWith(1))
-    await waitFor(() => expect(toast.success).toHaveBeenCalledWith('Certificate deleted'))
-    confirmSpy.mockRestore()
   })
 
-  it('deletes staging certificate when confirmed', async () => {
-    const confirmSpy = vi.spyOn(window, 'confirm').mockImplementation(() => true)
-    const { deleteCertificate } = await import('../../api/certificates')
-    const user = userEvent.setup()
-
-    renderWithClient(<CertificateList />)
-    const stagingButtons = await screen.findAllByTitle('Delete Staging Certificate')
-    expect(stagingButtons.length).toBeGreaterThan(0)
-    await user.click(stagingButtons[0])
-
-    await waitFor(() => expect(deleteCertificate).toHaveBeenCalledWith(2))
-    confirmSpy.mockRestore()
-  })
-
-  it('deletes valid custom certificate when not in use', async () => {
-    const confirmSpy = vi.spyOn(window, 'confirm').mockImplementation(() => true)
-    const { deleteCertificate } = await import('../../api/certificates')
+  it('does not call createBackup on delete (server handles it)', async () => {
     const { createBackup } = await import('../../api/backups')
     const user = userEvent.setup()
 
     renderWithClient(<CertificateList />)
     const rows = await screen.findAllByRole('row')
-    const unusedRow = rows.find(r => r.querySelector('td')?.textContent?.includes('UnusedValidCert')) as HTMLElement
-    expect(unusedRow).toBeTruthy()
-    const unusedButton = unusedRow.querySelector('button[title="Delete Certificate"]') as HTMLButtonElement
-    expect(unusedButton).toBeTruthy()
-    await user.click(unusedButton)
+    const customRow = rows.find(r => r.textContent?.includes('CustomCert'))!
+    await user.click(within(customRow).getByRole('button', { name: 'certificates.deleteTitle' }))
 
-    await waitFor(() => expect(createBackup).toHaveBeenCalled())
-    await waitFor(() => expect(deleteCertificate).toHaveBeenCalledWith(4))
-    confirmSpy.mockRestore()
+    const dialog = await screen.findByRole('dialog')
+    await user.click(within(dialog).getByRole('button', { name: 'certificates.deleteButton' }))
+    await waitFor(() => expect(createBackup).not.toHaveBeenCalled())
   })
 
   it('renders empty state when no certificates exist', async () => {
@@ -173,6 +257,157 @@ describe('CertificateList', () => {
     expect(await screen.findByText('Failed to load certificates')).toBeInTheDocument()
   })
 
+  it('shows error toast when delete mutation fails', async () => {
+    const { deleteCertificate } = await import('../../api/certificates')
+    const { toast } = await import('../../utils/toast')
+    vi.mocked(deleteCertificate).mockRejectedValueOnce(new Error('Network error'))
+    const user = userEvent.setup()
+
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const customRow = rows.find(r => r.textContent?.includes('CustomCert'))!
+    await user.click(within(customRow).getByRole('button', { name: 'certificates.deleteTitle' }))
+
+    const dialog = await screen.findByRole('dialog')
+    await user.click(within(dialog).getByRole('button', { name: 'certificates.deleteButton' }))
+
+    await waitFor(() => expect(toast.error).toHaveBeenCalledWith('certificates.deleteFailed: Network error'))
+  })
+
+  it('clicking disabled delete button for in-use cert does not open dialog', async () => {
+    const user = userEvent.setup()
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const activeRow = rows.find(r => r.textContent?.includes('ActiveCert'))!
+    const btn = within(activeRow).getByRole('button', { name: 'certificates.deleteTitle' })
+
+    await user.click(btn)
+    expect(screen.queryByRole('dialog')).not.toBeInTheDocument()
+  })
+
+  it('closes delete dialog when cancel is clicked', async () => {
+    const user = userEvent.setup()
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const customRow = rows.find(r => r.textContent?.includes('CustomCert'))!
+    await user.click(within(customRow).getByRole('button', { name: 'certificates.deleteTitle' }))
+
+    const dialog = await screen.findByRole('dialog')
+    expect(dialog).toBeInTheDocument()
+
+    await user.click(within(dialog).getByRole('button', { name: 'common.cancel' }))
+    await waitFor(() => expect(screen.queryByRole('dialog')).not.toBeInTheDocument())
+  })
+
+  it('renders enabled checkboxes for deletable not-in-use certs (ids 1, 2, 4, 5)', async () => {
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    for (const name of ['CustomCert', 'LE Staging', 'UnusedValidCert', 'ExpiredLE']) {
+      const row = rows.find(r => r.textContent?.includes(name))!
+      const checkbox = within(row).getByRole('checkbox')
+      expect(checkbox).toBeEnabled()
+      expect(checkbox).not.toHaveAttribute('aria-disabled', 'true')
+    }
+  })
+
+  it('renders disabled checkbox for in-use cert (id 3)', async () => {
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const activeRow = rows.find(r => r.textContent?.includes('ActiveCert'))!
+    const checkboxes = within(activeRow).getAllByRole('checkbox')
+    const rowCheckbox = checkboxes[0]
+    expect(rowCheckbox).toBeDisabled()
+    expect(rowCheckbox).toHaveAttribute('aria-disabled', 'true')
+  })
+
+  it('renders no checkbox in valid production LE cert row (id 6)', async () => {
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const validLeRow = rows.find(r => r.textContent?.includes('ValidLE'))!
+    expect(within(validLeRow).queryByRole('checkbox')).not.toBeInTheDocument()
+  })
+
+  it('selecting one cert makes the bulk action toolbar visible', async () => {
+    const user = userEvent.setup()
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const customRow = rows.find(r => r.textContent?.includes('CustomCert'))!
+    await user.click(within(customRow).getByRole('checkbox'))
+    expect(screen.getByRole('status')).toBeInTheDocument()
+  })
+
+  it('header select-all selects only ids 1, 2, 4, 5 (not in-use id 3)', async () => {
+    const user = userEvent.setup()
+    renderWithClient(<CertificateList />)
+    const headerRow = (await screen.findAllByRole('row'))[0]
+    const headerCheckbox = within(headerRow).getByRole('checkbox')
+    await user.click(headerCheckbox)
+    expect(screen.getByRole('status')).toBeInTheDocument()
+    const rows = screen.getAllByRole('row').slice(1)
+    const activeRow = rows.find(r => r.textContent?.includes('ActiveCert'))!
+    const activeCheckbox = within(activeRow).getByRole('checkbox')
+    expect(activeCheckbox).toBeDisabled()
+    expect(activeCheckbox).not.toBeChecked()
+  })
+
+  it('clicking the toolbar Delete button opens BulkDeleteCertificateDialog', async () => {
+    const user = userEvent.setup()
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const customRow = rows.find(r => r.textContent?.includes('CustomCert'))!
+    await user.click(within(customRow).getByRole('checkbox'))
+    await user.click(screen.getByRole('button', { name: /certificates\.bulkDeleteButton/i }))
+    expect(await screen.findByRole('dialog')).toBeInTheDocument()
+  })
+
+  it('confirming in the bulk dialog calls deleteCertificate for each selected ID', async () => {
+    const { deleteCertificate } = await import('../../api/certificates')
+    const user = userEvent.setup()
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const customRow = rows.find(r => r.textContent?.includes('CustomCert'))!
+    const stagingRow = rows.find(r => r.textContent?.includes('LE Staging'))!
+    await user.click(within(customRow).getByRole('checkbox'))
+    await user.click(within(stagingRow).getByRole('checkbox'))
+    await user.click(screen.getByRole('button', { name: /certificates\.bulkDeleteButton/i }))
+    const dialog = await screen.findByRole('dialog')
+    await user.click(within(dialog).getByRole('button', { name: /certificates\.bulkDeleteButton/i }))
+    await waitFor(() => {
+      expect(deleteCertificate).toHaveBeenCalledWith(1)
+      expect(deleteCertificate).toHaveBeenCalledWith(2)
+    })
+  })
+
+  it('shows partial failure toast when some bulk deletes fail', async () => {
+    const { deleteCertificate } = await import('../../api/certificates')
+    const { toast } = await import('../../utils/toast')
+    vi.mocked(deleteCertificate).mockImplementation(async (id: number) => {
+      if (id === 2) throw new Error('network error')
+    })
+    const user = userEvent.setup()
+    renderWithClient(<CertificateList />)
+    const rows = await screen.findAllByRole('row')
+    const customRow = rows.find(r => r.textContent?.includes('CustomCert'))!
+    const stagingRow = rows.find(r => r.textContent?.includes('LE Staging'))!
+    await user.click(within(customRow).getByRole('checkbox'))
+    await user.click(within(stagingRow).getByRole('checkbox'))
+    await user.click(screen.getByRole('button', { name: /certificates\.bulkDeleteButton/i }))
+    const dialog = await screen.findByRole('dialog')
+    await user.click(within(dialog).getByRole('button', { name: /certificates\.bulkDeleteButton/i }))
+    await waitFor(() => expect(toast.error).toHaveBeenCalledWith('certificates.bulkDeletePartial'))
+  })
+
+  it('clicking header checkbox twice deselects all and hides the bulk action toolbar', async () => {
+    const user = userEvent.setup()
+    renderWithClient(<CertificateList />)
+    const headerRow = (await screen.findAllByRole('row'))[0]
+    const headerCheckbox = within(headerRow).getByRole('checkbox')
+    await user.click(headerCheckbox)
+    expect(screen.getByRole('status')).toBeInTheDocument()
+    await user.click(headerCheckbox)
+    await waitFor(() => expect(screen.queryByRole('status')).not.toBeInTheDocument())
+  })
+
   it('sorts certificates by name and expiry when headers are clicked', async () => {
     const certificates: Certificate[] = [
       { id: 10, name: 'Zulu', domain: 'z.example.com', issuer: 'Custom CA', expires_at: '2026-03-01T00:00:00Z', status: 'valid', provider: 'custom' },

frontend/src/components/__tests__/SecurityNotificationSettingsModal.test.tsx

@@ -86,7 +86,7 @@ describe('Security Notification Settings on Notifications page', () => {
     await user.click(await screen.findByTestId('add-provider-btn'));
 
     const typeSelect = screen.getByTestId('provider-type') as HTMLSelectElement;
-    expect(Array.from(typeSelect.options).map((option) => option.value)).toEqual(['discord', 'gotify', 'webhook', 'email', 'telegram', 'slack', 'pushover']);
+    expect(Array.from(typeSelect.options).map((option) => option.value)).toEqual(['discord', 'gotify', 'webhook', 'email', 'telegram', 'slack', 'pushover', 'ntfy']);
     expect(typeSelect.value).toBe('discord');
 
     const webhookInput = screen.getByTestId('provider-url') as HTMLInputElement;

frontend/src/components/dialogs/BulkDeleteCertificateDialog.tsx

@@ -0,0 +1,88 @@
+import { AlertTriangle } from 'lucide-react'
+import { useTranslation } from 'react-i18next'
+
+import { Button } from '../ui/Button'
+import {
+  Dialog,
+  DialogContent,
+  DialogDescription,
+  DialogFooter,
+  DialogHeader,
+  DialogTitle,
+} from '../ui/Dialog'
+
+import type { Certificate } from '../../api/certificates'
+
+interface BulkDeleteCertificateDialogProps {
+  certificates: Certificate[]
+  open: boolean
+  onConfirm: () => void
+  onCancel: () => void
+  isDeleting: boolean
+}
+
+function providerLabel(cert: Certificate, t: (key: string) => string): string {
+  if (cert.provider === 'letsencrypt-staging') return t('certificates.providerStaging')
+  if (cert.provider === 'custom') return t('certificates.providerCustom')
+  if (cert.status === 'expired') return t('certificates.providerExpiredLE')
+  if (cert.status === 'expiring') return t('certificates.providerExpiringLE')
+  return cert.provider
+}
+
+export default function BulkDeleteCertificateDialog({
+  certificates,
+  open,
+  onConfirm,
+  onCancel,
+  isDeleting,
+}: BulkDeleteCertificateDialogProps) {
+  const { t } = useTranslation()
+
+  if (certificates.length === 0) return null
+
+  return (
+    <Dialog open={open} onOpenChange={(isOpen) => { if (!isOpen) onCancel() }}>
+      <DialogContent className="max-w-lg">
+        <DialogHeader>
+          <DialogTitle>{t('certificates.bulkDeleteTitle', { count: certificates.length })}</DialogTitle>
+          <DialogDescription>
+            {t('certificates.bulkDeleteDescription', { count: certificates.length })}
+          </DialogDescription>
+        </DialogHeader>
+
+        <div className="px-6 space-y-4">
+          <div className="flex items-start gap-3 rounded-lg border border-red-900/50 bg-red-900/10 p-4">
+            <AlertTriangle className="h-5 w-5 shrink-0 text-red-400 mt-0.5" />
+            <p className="text-sm text-gray-300">
+              {t('certificates.bulkDeleteConfirm')}
+            </p>
+          </div>
+
+          <ul
+            aria-label={t('certificates.bulkDeleteListAriaLabel')}
+            className="max-h-48 overflow-y-auto rounded-lg border border-gray-800 divide-y divide-gray-800"
+          >
+            {certificates.map((cert) => (
+              <li
+                key={cert.id ?? cert.domain}
+                className="flex items-center justify-between px-4 py-2"
+              >
+                <span className="text-sm text-white">{cert.name || cert.domain}</span>
+                <span className="text-xs text-gray-500">{providerLabel(cert, t)}</span>
+              </li>
+            ))}
+          </ul>
+        </div>
+
+        <DialogFooter>
+          <Button variant="secondary" onClick={onCancel} disabled={isDeleting}>
+            {t('common.cancel')}
+          </Button>
+          <Button variant="danger" onClick={onConfirm} isLoading={isDeleting}>
+            {t('certificates.bulkDeleteButton', { count: certificates.length })}
+          </Button>
+        </DialogFooter>
+      </DialogContent>
+    </Dialog>
+  )
+}

frontend/src/components/dialogs/DeleteCertificateDialog.tsx

@@ -0,0 +1,81 @@
+import { AlertTriangle } from 'lucide-react'
+import { useTranslation } from 'react-i18next'
+
+import { Button } from '../ui/Button'
+import {
+  Dialog,
+  DialogContent,
+  DialogDescription,
+  DialogFooter,
+  DialogHeader,
+  DialogTitle,
+} from '../ui/Dialog'
+
+import type { Certificate } from '../../api/certificates'
+
+interface DeleteCertificateDialogProps {
+  certificate: Certificate | null
+  open: boolean
+  onConfirm: () => void
+  onCancel: () => void
+  isDeleting: boolean
+}
+
+function getWarningKey(cert: Certificate): string {
+  if (cert.status === 'expired') return 'certificates.deleteConfirmExpired'
+  if (cert.status === 'expiring') return 'certificates.deleteConfirmExpiring'
+  if (cert.provider === 'letsencrypt-staging') return 'certificates.deleteConfirmStaging'
+  return 'certificates.deleteConfirmCustom'
+}
+
+export default function DeleteCertificateDialog({
+  certificate,
+  open,
+  onConfirm,
+  onCancel,
+  isDeleting,
+}: DeleteCertificateDialogProps) {
+  const { t } = useTranslation()
+
+  if (!certificate) return null
+
+  return (
+    <Dialog open={open} onOpenChange={(isOpen) => { if (!isOpen) onCancel() }}>
+      <DialogContent>
+        <DialogHeader>
+          <DialogTitle>{t('certificates.deleteTitle')}</DialogTitle>
+          <DialogDescription>
+            {certificate.name || certificate.domain}
+          </DialogDescription>
+        </DialogHeader>
+
+        <div className="px-6 space-y-4">
+          <div className="flex items-start gap-3 rounded-lg border border-red-900/50 bg-red-900/10 p-4">
+            <AlertTriangle className="h-5 w-5 shrink-0 text-red-400 mt-0.5" />
+            <p className="text-sm text-gray-300">
+              {t(getWarningKey(certificate))}
+            </p>
+          </div>
+
+          <dl className="grid grid-cols-[auto_1fr] gap-x-4 gap-y-1 text-sm">
+            <dt className="text-gray-500">{t('certificates.domain')}</dt>
+            <dd className="text-white">{certificate.domain}</dd>
+            <dt className="text-gray-500">{t('certificates.status')}</dt>
+            <dd className="text-white capitalize">{certificate.status}</dd>
+            <dt className="text-gray-500">{t('certificates.provider')}</dt>
+            <dd className="text-white">{certificate.provider}</dd>
+          </dl>
+        </div>
+
+        <DialogFooter>
+          <Button variant="secondary" onClick={onCancel} disabled={isDeleting}>
+            {t('common.cancel')}
+          </Button>
+          <Button variant="danger" onClick={onConfirm} isLoading={isDeleting}>
+            {t('certificates.deleteButton')}
+          </Button>
+        </DialogFooter>
+      </DialogContent>
+    </Dialog>
+  )
+}

frontend/src/components/dialogs/__tests__/BulkDeleteCertificateDialog.test.tsx

@@ -0,0 +1,136 @@
+import { render, screen, within } from '@testing-library/react'
+import userEvent from '@testing-library/user-event'
+import { describe, it, expect, vi } from 'vitest'
+
+import BulkDeleteCertificateDialog from '../../dialogs/BulkDeleteCertificateDialog'
+
+import type { Certificate } from '../../../api/certificates'
+
+const makeCert = (overrides: Partial<Certificate>): Certificate => ({
+  id: 1,
+  name: 'Test Cert',
+  domain: 'test.example.com',
+  issuer: 'Custom CA',
+  expires_at: '2026-01-01T00:00:00Z',
+  status: 'valid',
+  provider: 'custom',
+  ...overrides,
+})
+
+const certs: Certificate[] = [
+  makeCert({ id: 1, name: 'Cert One', domain: 'one.example.com' }),
+  makeCert({ id: 2, name: 'Cert Two', domain: 'two.example.com', provider: 'letsencrypt-staging', status: 'untrusted' }),
+  makeCert({ id: 3, name: 'Cert Three', domain: 'three.example.com', provider: 'letsencrypt', status: 'expired' }),
+]
+
+describe('BulkDeleteCertificateDialog', () => {
+  it('renders dialog with count in title when 3 certs supplied', () => {
+    render(
+      <BulkDeleteCertificateDialog
+        certificates={certs}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    const dialog = screen.getByRole('dialog')
+    expect(within(dialog).getByRole('heading', { name: 'Delete 3 Certificate(s)' })).toBeInTheDocument()
+  })
+
+  it('lists each certificate name in the scrollable list', () => {
+    render(
+      <BulkDeleteCertificateDialog
+        certificates={certs}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    expect(screen.getByText('Cert One')).toBeInTheDocument()
+    expect(screen.getByText('Cert Two')).toBeInTheDocument()
+    expect(screen.getByText('Cert Three')).toBeInTheDocument()
+    expect(screen.getByText('Custom')).toBeInTheDocument()
+    expect(screen.getByText('Staging')).toBeInTheDocument()
+    expect(screen.getByText('Expired LE')).toBeInTheDocument()
+  })
+
+  it('calls onConfirm when the Delete button is clicked', async () => {
+    const onConfirm = vi.fn()
+    const user = userEvent.setup()
+    render(
+      <BulkDeleteCertificateDialog
+        certificates={certs}
+        open={true}
+        onConfirm={onConfirm}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    const dialog = screen.getByRole('dialog')
+    await user.click(within(dialog).getByRole('button', { name: 'Delete 3 Certificate(s)' }))
+    expect(onConfirm).toHaveBeenCalled()
+  })
+
+  it('calls onCancel when the Cancel button is clicked', async () => {
+    const onCancel = vi.fn()
+    const user = userEvent.setup()
+    render(
+      <BulkDeleteCertificateDialog
+        certificates={certs}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={onCancel}
+        isDeleting={false}
+      />
+    )
+    const dialog = screen.getByRole('dialog')
+    await user.click(within(dialog).getByRole('button', { name: 'Cancel' }))
+    expect(onCancel).toHaveBeenCalled()
+  })
+
+  it('Delete button is loading/disabled when isDeleting is true', () => {
+    render(
+      <BulkDeleteCertificateDialog
+        certificates={certs}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={true}
+      />
+    )
+    const dialog = screen.getByRole('dialog')
+    const deleteBtn = within(dialog).getByRole('button', { name: 'Delete 3 Certificate(s)' })
+    expect(deleteBtn).toBeDisabled()
+    const cancelBtn = within(dialog).getByRole('button', { name: 'Cancel' })
+    expect(cancelBtn).toBeDisabled()
+  })
+
+  it('returns null when certificates array is empty', () => {
+    const { container } = render(
+      <BulkDeleteCertificateDialog
+        certificates={[]}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    expect(container.innerHTML).toBe('')
+  })
+
+  it('renders "Expiring LE" label for a letsencrypt cert with status expiring', () => {
+    const expiringCert = makeCert({ id: 4, name: 'Expiring Cert', domain: 'expiring.example.com', provider: 'letsencrypt', status: 'expiring' })
+    render(
+      <BulkDeleteCertificateDialog
+        certificates={[expiringCert]}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    expect(screen.getByText('Expiring LE')).toBeInTheDocument()
+  })
+})

frontend/src/components/dialogs/__tests__/DeleteCertificateDialog.test.tsx

@@ -0,0 +1,128 @@
+import { render, screen } from '@testing-library/react'
+import userEvent from '@testing-library/user-event'
+import { describe, it, expect, vi } from 'vitest'
+
+import DeleteCertificateDialog from '../../dialogs/DeleteCertificateDialog'
+
+import type { Certificate } from '../../../api/certificates'
+
+vi.mock('react-i18next', () => ({
+  useTranslation: () => ({
+    t: (key: string) => key,
+    i18n: { language: 'en', changeLanguage: vi.fn() },
+  }),
+}))
+
+const baseCert: Certificate = {
+  id: 1,
+  name: 'Test Cert',
+  domain: 'test.example.com',
+  issuer: 'Custom CA',
+  expires_at: '2026-01-01T00:00:00Z',
+  status: 'valid',
+  provider: 'custom',
+}
+
+describe('DeleteCertificateDialog', () => {
+  it('renders warning text for custom cert', () => {
+    render(
+      <DeleteCertificateDialog
+        certificate={baseCert}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    expect(screen.getByText('certificates.deleteConfirmCustom')).toBeInTheDocument()
+    expect(screen.getByText('certificates.deleteTitle')).toBeInTheDocument()
+  })
+
+  it('renders warning text for staging cert', () => {
+    const staging: Certificate = { ...baseCert, provider: 'letsencrypt-staging', status: 'untrusted' }
+    render(
+      <DeleteCertificateDialog
+        certificate={staging}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    expect(screen.getByText('certificates.deleteConfirmStaging')).toBeInTheDocument()
+  })
+
+  it('renders warning text for expired cert', () => {
+    const expired: Certificate = { ...baseCert, provider: 'letsencrypt', status: 'expired' }
+    render(
+      <DeleteCertificateDialog
+        certificate={expired}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    expect(screen.getByText('certificates.deleteConfirmExpired')).toBeInTheDocument()
+  })
+
+  it('calls onCancel when Cancel is clicked', async () => {
+    const onCancel = vi.fn()
+    const user = userEvent.setup()
+    render(
+      <DeleteCertificateDialog
+        certificate={baseCert}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={onCancel}
+        isDeleting={false}
+      />
+    )
+    await user.click(screen.getByRole('button', { name: 'common.cancel' }))
+    expect(onCancel).toHaveBeenCalled()
+  })
+
+  it('calls onConfirm when Delete is clicked', async () => {
+    const onConfirm = vi.fn()
+    const user = userEvent.setup()
+    render(
+      <DeleteCertificateDialog
+        certificate={baseCert}
+        open={true}
+        onConfirm={onConfirm}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    await user.click(screen.getByRole('button', { name: 'certificates.deleteButton' }))
+    expect(onConfirm).toHaveBeenCalled()
+  })
+
+  it('renders nothing when certificate is null', () => {
+    const { container } = render(
+      <DeleteCertificateDialog
+        certificate={null}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    expect(container.innerHTML).toBe('')
+  })
+
+  it('renders expired warning for expired staging cert (priority ordering)', () => {
+    const expiredStaging: Certificate = { ...baseCert, provider: 'letsencrypt-staging', status: 'expired' }
+    render(
+      <DeleteCertificateDialog
+        certificate={expiredStaging}
+        open={true}
+        onConfirm={vi.fn()}
+        onCancel={vi.fn()}
+        isDeleting={false}
+      />
+    )
+    expect(screen.getByText('certificates.deleteConfirmExpired')).toBeInTheDocument()
+    expect(screen.queryByText('certificates.deleteConfirmStaging')).not.toBeInTheDocument()
+  })
+})

frontend/src/locales/de/translation.json

@@ -173,7 +173,32 @@
     "uploadSuccess": "Zertifikat erfolgreich hochgeladen",
     "uploadFailed": "Fehler beim Hochladen des Zertifikats",
     "note": "Hinweis",
-    "noteText": "Sie können benutzerdefinierte Zertifikate und Staging-Zertifikate löschen. Produktions-Let's-Encrypt-Zertifikate werden automatisch erneuert und sollten nur beim Umgebungswechsel gelöscht werden."
+    "noteText": "Sie können benutzerdefinierte Zertifikate, Staging-Zertifikate sowie abgelaufene oder ablaufende Produktionszertifikate löschen, die keinem Proxy-Host zugeordnet sind. Aktive Produktionszertifikate werden von Caddy automatisch erneuert.",
+    "provider": "Provider",
+    "deleteTitle": "Delete Certificate",
+    "deleteConfirmCustom": "This will permanently delete this certificate. A backup will be created first.",
+    "deleteConfirmStaging": "This staging certificate will be removed. It will be regenerated on next request.",
+    "deleteConfirmExpired": "This expired certificate is no longer active and will be permanently removed.",
+    "deleteConfirmExpiring": "This certificate is expiring soon. It will be permanently removed and will not be auto-renewed.",
+    "deleteSuccess": "Certificate deleted",
+    "deleteFailed": "Failed to delete certificate",
+    "deleteInUse": "Cannot delete — certificate is attached to a proxy host",
+    "deleteButton": "Delete",
+    "bulkSelectAll": "Alle löschbaren Zertifikate auswählen",
+    "selectCert": "Zertifikat {{name}} auswählen",
+    "bulkSelectedCount": "{{count}} Zertifikat(e) ausgewählt",
+    "bulkDeleteTitle": "{{count}} Zertifikat(e) löschen",
+    "bulkDeleteDescription": "{{count}} Zertifikat(e) löschen",
+    "bulkDeleteConfirm": "Die folgenden Zertifikate werden dauerhaft gelöscht. Der Server erstellt vor jeder Löschung eine Sicherung.",
+    "bulkDeleteListAriaLabel": "Zu löschende Zertifikate",
+    "bulkDeleteButton": "{{count}} Zertifikat(e) löschen",
+    "bulkDeleteSuccess": "{{count}} Zertifikat(e) gelöscht",
+    "bulkDeletePartial": "{{deleted}} gelöscht, {{failed}} fehlgeschlagen",
+    "bulkDeleteFailed": "Zertifikate konnten nicht gelöscht werden",
+    "providerStaging": "Staging",
+    "providerCustom": "Benutzerdefiniert",
+    "providerExpiredLE": "Abgelaufen LE",
+    "providerExpiringLE": "Ablaufend LE"
   },
   "auth": {
     "login": "Anmelden",
@@ -506,7 +531,12 @@
     "webhookUrl": "Webhook URL (Optional)",
     "webhookUrlHelp": "POST requests will be sent to this URL when security events occur.",
     "emailRecipients": "Email Recipients (Optional)",
-    "emailRecipientsHelp": "Comma-separated email addresses."
+    "emailRecipientsHelp": "Comma-separated email addresses.",
+    "ntfy": "Ntfy",
+    "ntfyTopicUrl": "Topic URL",
+    "ntfyAccessToken": "Access Token (optional)",
+    "ntfyAccessTokenPlaceholder": "Enter your Ntfy access token",
+    "ntfyAccessTokenHelp": "Your Ntfy access token for authenticated topics. Required for password-protected topics on self-hosted instances. The token is stored securely and separately."
   },
   "users": {
     "title": "Benutzerverwaltung",

frontend/src/locales/en/translation.json

@@ -182,7 +182,32 @@
     "uploadSuccess": "Certificate uploaded successfully",
     "uploadFailed": "Failed to upload certificate",
     "note": "Note",
-    "noteText": "You can delete custom certificates and staging certificates. Production Let's Encrypt certificates are automatically renewed and should not be deleted unless switching environments."
+    "noteText": "You can delete custom certificates, staging certificates, and expired or expiring production certificates that are not attached to any proxy host. Active production certificates are automatically renewed by Caddy.",
+    "provider": "Provider",
+    "deleteTitle": "Delete Certificate",
+    "deleteConfirmCustom": "This will permanently delete this certificate. A backup will be created first.",
+    "deleteConfirmStaging": "This staging certificate will be removed. It will be regenerated on next request.",
+    "deleteConfirmExpired": "This expired certificate is no longer active and will be permanently removed.",
+    "deleteConfirmExpiring": "This certificate is expiring soon. It will be permanently removed and will not be auto-renewed.",
+    "deleteSuccess": "Certificate deleted",
+    "deleteFailed": "Failed to delete certificate",
+    "deleteInUse": "Cannot delete — certificate is attached to a proxy host",
+    "deleteButton": "Delete",
+    "bulkSelectAll": "Select all deletable certificates",
+    "selectCert": "Select certificate {{name}}",
+    "bulkSelectedCount": "{{count}} certificate(s) selected",
+    "bulkDeleteTitle": "Delete {{count}} Certificate(s)",
+    "bulkDeleteDescription": "Delete {{count}} certificate(s)",
+    "bulkDeleteConfirm": "The following certificates will be permanently deleted. The server creates a backup before each removal.",
+    "bulkDeleteListAriaLabel": "Certificates to be deleted",
+    "bulkDeleteButton": "Delete {{count}} Certificate(s)",
+    "bulkDeleteSuccess": "{{count}} certificate(s) deleted",
+    "bulkDeletePartial": "{{deleted}} deleted, {{failed}} failed",
+    "bulkDeleteFailed": "Failed to delete certificates",
+    "providerStaging": "Staging",
+    "providerCustom": "Custom",
+    "providerExpiredLE": "Expired LE",
+    "providerExpiringLE": "Expiring LE"
   },
   "auth": {
     "login": "Login",
@@ -603,7 +628,12 @@
     "pushoverApiTokenPlaceholder": "Enter your Pushover Application API Token",
     "pushoverUserKey": "User Key",
     "pushoverUserKeyPlaceholder": "uQiRzpo4DXghDmr9QzzfQu27cmVRsG",
-    "pushoverUserKeyHelp": "Your Pushover user or group key. The API token is stored securely and separately."
+    "pushoverUserKeyHelp": "Your Pushover user or group key. The API token is stored securely and separately.",
+    "ntfy": "Ntfy",
+    "ntfyTopicUrl": "Topic URL",
+    "ntfyAccessToken": "Access Token (optional)",
+    "ntfyAccessTokenPlaceholder": "Enter your Ntfy access token",
+    "ntfyAccessTokenHelp": "Your Ntfy access token for authenticated topics. Required for password-protected topics on self-hosted instances. The token is stored securely and separately."
   },
   "users": {
     "title": "User Management",

frontend/src/locales/es/translation.json

@@ -173,7 +173,32 @@
     "uploadSuccess": "Certificado subido exitosamente",
     "uploadFailed": "Error al subir el certificado",
     "note": "Nota",
-    "noteText": "Puedes eliminar certificados personalizados y certificados de prueba. Los certificados de Let's Encrypt de producción se renuevan automáticamente y no deben eliminarse a menos que cambies de entorno."
+    "noteText": "Puedes eliminar certificados personalizados, certificados de staging y certificados de producción vencidos o por vencer que no estén vinculados a ningún host proxy. Los certificados de producción activos se renuevan automáticamente mediante Caddy.",
+    "provider": "Provider",
+    "deleteTitle": "Delete Certificate",
+    "deleteConfirmCustom": "This will permanently delete this certificate. A backup will be created first.",
+    "deleteConfirmStaging": "This staging certificate will be removed. It will be regenerated on next request.",
+    "deleteConfirmExpired": "This expired certificate is no longer active and will be permanently removed.",
+    "deleteConfirmExpiring": "This certificate is expiring soon. It will be permanently removed and will not be auto-renewed.",
+    "deleteSuccess": "Certificate deleted",
+    "deleteFailed": "Failed to delete certificate",
+    "deleteInUse": "Cannot delete — certificate is attached to a proxy host",
+    "deleteButton": "Delete",
+    "bulkSelectAll": "Seleccionar todos los certificados eliminables",
+    "selectCert": "Seleccionar certificado {{name}}",
+    "bulkSelectedCount": "{{count}} certificado(s) seleccionado(s)",
+    "bulkDeleteTitle": "Eliminar {{count}} Certificado(s)",
+    "bulkDeleteDescription": "Eliminar {{count}} certificado(s)",
+    "bulkDeleteConfirm": "Los siguientes certificados se eliminarán permanentemente. El servidor crea una copia de seguridad antes de cada eliminación.",
+    "bulkDeleteListAriaLabel": "Certificados a eliminar",
+    "bulkDeleteButton": "Eliminar {{count}} Certificado(s)",
+    "bulkDeleteSuccess": "{{count}} certificado(s) eliminado(s)",
+    "bulkDeletePartial": "{{deleted}} eliminado(s), {{failed}} fallido(s)",
+    "bulkDeleteFailed": "No se pudieron eliminar los certificados",
+    "providerStaging": "Pruebas",
+    "providerCustom": "Personalizado",
+    "providerExpiredLE": "LE Expirado",
+    "providerExpiringLE": "LE Por expirar"
   },
   "auth": {
     "login": "Iniciar Sesión",
@@ -506,7 +531,12 @@
     "webhookUrl": "Webhook URL (Optional)",
     "webhookUrlHelp": "POST requests will be sent to this URL when security events occur.",
     "emailRecipients": "Email Recipients (Optional)",
-    "emailRecipientsHelp": "Comma-separated email addresses."
+    "emailRecipientsHelp": "Comma-separated email addresses.",
+    "ntfy": "Ntfy",
+    "ntfyTopicUrl": "Topic URL",
+    "ntfyAccessToken": "Access Token (optional)",
+    "ntfyAccessTokenPlaceholder": "Enter your Ntfy access token",
+    "ntfyAccessTokenHelp": "Your Ntfy access token for authenticated topics. Required for password-protected topics on self-hosted instances. The token is stored securely and separately."
   },
   "users": {
     "title": "Gestión de Usuarios",

frontend/src/locales/fr/translation.json

@@ -173,7 +173,32 @@
     "uploadSuccess": "Certificat téléversé avec succès",
     "uploadFailed": "Échec du téléversement du certificat",
     "note": "Note",
-    "noteText": "Vous pouvez supprimer les certificats personnalisés et les certificats de test. Les certificats Let's Encrypt de production sont renouvelés automatiquement et ne doivent pas être supprimés sauf en cas de changement d'environnement."
+    "noteText": "Vous pouvez supprimer les certificats personnalisés, les certificats de staging et les certificats de production expirés ou arrivant à expiration qui ne sont associés à aucun hôte proxy. Les certificats de production actifs sont renouvelés automatiquement par Caddy.",
+    "provider": "Provider",
+    "deleteTitle": "Delete Certificate",
+    "deleteConfirmCustom": "This will permanently delete this certificate. A backup will be created first.",
+    "deleteConfirmStaging": "This staging certificate will be removed. It will be regenerated on next request.",
+    "deleteConfirmExpired": "This expired certificate is no longer active and will be permanently removed.",
+    "deleteConfirmExpiring": "This certificate is expiring soon. It will be permanently removed and will not be auto-renewed.",
+    "deleteSuccess": "Certificate deleted",
+    "deleteFailed": "Failed to delete certificate",
+    "deleteInUse": "Cannot delete — certificate is attached to a proxy host",
+    "deleteButton": "Delete",
+    "bulkSelectAll": "Sélectionner tous les certificats supprimables",
+    "selectCert": "Sélectionner le certificat {{name}}",
+    "bulkSelectedCount": "{{count}} certificat(s) sélectionné(s)",
+    "bulkDeleteTitle": "Supprimer {{count}} Certificat(s)",
+    "bulkDeleteDescription": "Supprimer {{count}} certificat(s)",
+    "bulkDeleteConfirm": "Les certificats suivants seront définitivement supprimés. Le serveur crée une sauvegarde avant chaque suppression.",
+    "bulkDeleteListAriaLabel": "Certificats à supprimer",
+    "bulkDeleteButton": "Supprimer {{count}} Certificat(s)",
+    "bulkDeleteSuccess": "{{count}} certificat(s) supprimé(s)",
+    "bulkDeletePartial": "{{deleted}} supprimé(s), {{failed}} échoué(s)",
+    "bulkDeleteFailed": "Impossible de supprimer les certificats",
+    "providerStaging": "Test",
+    "providerCustom": "Personnalisé",
+    "providerExpiredLE": "LE Expiré",
+    "providerExpiringLE": "LE Expirant"
   },
   "auth": {
     "login": "Connexion",
@@ -506,7 +531,12 @@
     "webhookUrl": "Webhook URL (Optional)",
     "webhookUrlHelp": "POST requests will be sent to this URL when security events occur.",
     "emailRecipients": "Email Recipients (Optional)",
-    "emailRecipientsHelp": "Comma-separated email addresses."
+    "emailRecipientsHelp": "Comma-separated email addresses.",
+    "ntfy": "Ntfy",
+    "ntfyTopicUrl": "Topic URL",
+    "ntfyAccessToken": "Access Token (optional)",
+    "ntfyAccessTokenPlaceholder": "Enter your Ntfy access token",
+    "ntfyAccessTokenHelp": "Your Ntfy access token for authenticated topics. Required for password-protected topics on self-hosted instances. The token is stored securely and separately."
   },
   "users": {
     "title": "Gestion des Utilisateurs",

frontend/src/locales/zh/translation.json

@@ -173,7 +173,32 @@
     "uploadSuccess": "证书上传成功",
     "uploadFailed": "证书上传失败",
     "note": "注意",
-    "noteText": "您可以删除自定义证书和测试证书。生产环境的Let's Encrypt证书会自动续期，除非切换环境否则不应删除。"
+    "noteText": "您可以删除未附加到任何代理主机的自定义证书、暂存证书以及已过期或即将过期的生产证书。活跃的生产证书由 Caddy 自动续期。",
+    "provider": "Provider",
+    "deleteTitle": "Delete Certificate",
+    "deleteConfirmCustom": "This will permanently delete this certificate. A backup will be created first.",
+    "deleteConfirmStaging": "This staging certificate will be removed. It will be regenerated on next request.",
+    "deleteConfirmExpired": "This expired certificate is no longer active and will be permanently removed.",
+    "deleteConfirmExpiring": "This certificate is expiring soon. It will be permanently removed and will not be auto-renewed.",
+    "deleteSuccess": "Certificate deleted",
+    "deleteFailed": "Failed to delete certificate",
+    "deleteInUse": "Cannot delete — certificate is attached to a proxy host",
+    "deleteButton": "Delete",
+    "bulkSelectAll": "选择所有可删除的证书",
+    "selectCert": "选择证书 {{name}}",
+    "bulkSelectedCount": "已选择 {{count}} 个证书",
+    "bulkDeleteTitle": "删除 {{count}} 个证书",
+    "bulkDeleteDescription": "删除 {{count}} 个证书",
+    "bulkDeleteConfirm": "以下证书将被永久删除。服务器在每次删除前会创建备份。",
+    "bulkDeleteListAriaLabel": "将被删除的证书",
+    "bulkDeleteButton": "删除 {{count}} 个证书",
+    "bulkDeleteSuccess": "已删除 {{count}} 个证书",
+    "bulkDeletePartial": "已删除 {{deleted}} 个，{{failed}} 个失败",
+    "bulkDeleteFailed": "证书删除失败",
+    "providerStaging": "测试",
+    "providerCustom": "自定义",
+    "providerExpiredLE": "已过期 LE",
+    "providerExpiringLE": "即将过期 LE"
   },
   "auth": {
     "login": "登录",
@@ -506,7 +531,12 @@
     "webhookUrl": "Webhook URL (Optional)",
     "webhookUrlHelp": "POST requests will be sent to this URL when security events occur.",
     "emailRecipients": "Email Recipients (Optional)",
-    "emailRecipientsHelp": "Comma-separated email addresses."
+    "emailRecipientsHelp": "Comma-separated email addresses.",
+    "ntfy": "Ntfy",
+    "ntfyTopicUrl": "Topic URL",
+    "ntfyAccessToken": "Access Token (optional)",
+    "ntfyAccessTokenPlaceholder": "Enter your Ntfy access token",
+    "ntfyAccessTokenHelp": "Your Ntfy access token for authenticated topics. Required for password-protected topics on self-hosted instances. The token is stored securely and separately."
   },
   "users": {
     "title": "用户管理",