Skip to content
ChannelWatch

CSP, CSRF, Cookies

ChannelWatch v1.0 ships with a set of web hardening defaults that apply to every page and API endpoint. These are on by default and require no configuration for standard deployments.

Content Security Policy

Section titled “Content Security Policy”

ChannelWatch sets a Content-Security-Policy header on all responses from the web UI. The policy restricts which sources the browser will load scripts, styles, images, and other resources from.

The default policy is intentionally strict for a self-hosted tool:

  • Scripts and styles are loaded only from the same origin ('self').
  • No inline scripts are allowed (prevents XSS via injected markup).
  • No external CDN dependencies in the UI (all assets are bundled).
  • frame-ancestors 'none' prevents the UI from being embedded in an iframe on another site.

If you run ChannelWatch behind a reverse proxy that injects its own headers, make sure the proxy does not strip or override the Content-Security-Policy header.

CSRF protection

Section titled “CSRF protection”

All state-changing requests (POST, PUT, PATCH, DELETE) require a CSRF token. The token is issued as a cookie on page load and must be included as a request header (X-CSRF-Token) on every mutating request.

Browser sessions handle this automatically. If you’re building automation against the API, use the API key authentication path instead of session cookies — API key requests are exempt from CSRF checks because they don’t rely on cookie-based authentication.

Section titled “Secure cookie flags”

Session cookies are set with the following flags:

FlagValueEffect
HttpOnlyAlwaysJavaScript cannot read the session cookie
SameSiteStrictCookie is not sent on cross-site requests
SecureWhen behind HTTPSCookie is only sent over encrypted connections

The Secure flag is applied automatically when ChannelWatch detects it is running behind a TLS-terminating reverse proxy (detected via the X-Forwarded-Proto: https header). If you run ChannelWatch directly on HTTPS, the flag is also applied.

Threat model

Section titled “Threat model”

The following is the honest threat model for ChannelWatch v1.0. Understanding what the security features protect against, and what they don’t, helps you make informed decisions about your deployment.

What encryption at rest protects against: If someone reads your settings.json file (for example, from a backup that was accidentally shared), they will see "api_key": "fernet:..." instead of a plaintext credential. The encryption prevents accidental plaintext exposure on disk.

What encryption at rest does NOT protect against: If an attacker has read access to your /config directory, they have both the encrypted data and the encryption key (/config/encryption.key). Encryption at rest is not a substitute for filesystem access control. Protect your config volume with appropriate permissions.

What RBAC protects against: Unauthorized users accessing the dashboard or API when ChannelWatch is reachable by multiple people on your network.

What RBAC does NOT protect against: Network-level attacks. RBAC is an application-layer control. If your ChannelWatch instance is reachable from the internet without a firewall or reverse proxy, RBAC alone is not sufficient.

What CSP and CSRF protect against: Cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks from malicious web pages that try to interact with your ChannelWatch instance through your browser.

What CSP and CSRF do NOT protect against: Attacks that originate from within your network or from a compromised device that already has access to the ChannelWatch URL.

Reporting vulnerabilities

Section titled “Reporting vulnerabilities”

ChannelWatch uses GitHub’s private security advisory system for vulnerability reports. This keeps the details confidential until a fix is ready.

To report a vulnerability:

  1. Go to the ChannelWatch GitHub repository.
  2. Click Security in the top navigation.
  3. Click Report a vulnerability.
  4. Fill in the advisory form with a description, reproduction steps, and potential impact.

Response SLA:

  • Acknowledgment within 48 hours of receipt.
  • Initial assessment and response within 5 business days.
  • Fix timeline communicated after assessment.

Please do not open a public issue for security vulnerabilities. Public disclosure before a fix is available puts all users at risk.

Once a fix is released, the vulnerability will be disclosed in the GitHub security advisory and in the release notes for the affected version.

Reverse proxy recommendations

Section titled “Reverse proxy recommendations”

If you expose ChannelWatch outside your local network, run it behind a reverse proxy with TLS. A minimal Nginx configuration:

server {
    listen 443 ssl;
    server_name channelwatch.example.com;


    ssl_certificate     /etc/ssl/certs/channelwatch.crt;
    ssl_certificate_key /etc/ssl/private/channelwatch.key;


    location / {
        proxy_pass http://127.0.0.1:8501;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
    }
}

The X-Forwarded-Proto: https header tells ChannelWatch to set the Secure flag on session cookies.

Section titled “Related pages”