Context
My project enforces a strict Content Security Policy. Currently in report-only mode, it is moving toward full enforcement. The policy includes:
style-src: 'self'
This means no inline <style> elements are permitted — only stylesheets served from the same origin.
Problem
The altcha.min.js bundled by django-altcha is altcha's standard bundle, which injects an inline <style> element at runtime. This triggers a CSP violation:
Content-Security-Policy: The page's settings would block the application of an inline style (style-src-elem) because it violates the directive style-src 'self'. Consider using a hash
(sha256-pg+oQARqMq4wCazyrsMt8HY89BJkXkEFkwNWxg2iPdg=) or a nonce.
The workaround of hardcoding the SHA256 hash in the CSP is fragile: it is tied to a specific version of altcha and will silently break the widget on any upgrade.
Request
The altcha project itself already provides a strict-CSP build in /dist_external:
altcha/external — web component without injected CSS or embedded worker
altcha/worker — separate web worker file
altcha/altcha.css — external stylesheet
Could django-altcha ship these additional assets and expose a configuration option (e.g. ALTCHA_STRICT_CSP = True) that:
- Serves
altcha/external and altcha/worker instead of altcha.min.js
- Serves
altcha/altcha.css as a separate static file (or exposes its path so the project can include it in its own stylesheet)
This would allow projects with strict CSPs to use the widget without any unsafe-inline or hash workarounds.
I'm happy to contribute a PR. Please note it will be AI generated, then humanly reviewed and tested 👍 Let me know what you think.
References
Context
My project enforces a strict Content Security Policy. Currently in report-only mode, it is moving toward full enforcement. The policy includes:
style-src: 'self'
This means no inline
<style>elements are permitted — only stylesheets served from the same origin.Problem
The
altcha.min.jsbundled by django-altcha is altcha's standard bundle, which injects an inline<style>element at runtime. This triggers a CSP violation:The workaround of hardcoding the SHA256 hash in the CSP is fragile: it is tied to a specific version of altcha and will silently break the widget on any upgrade.
Request
The altcha project itself already provides a strict-CSP build in
/dist_external:altcha/external— web component without injected CSS or embedded workeraltcha/worker— separate web worker filealtcha/altcha.css— external stylesheetCould django-altcha ship these additional assets and expose a configuration option (e.g.
ALTCHA_STRICT_CSP = True) that:altcha/externalandaltcha/workerinstead ofaltcha.min.jsaltcha/altcha.cssas a separate static file (or exposes its path so the project can include it in its own stylesheet)This would allow projects with strict CSPs to use the widget without any
unsafe-inlineor hash workarounds.I'm happy to contribute a PR. Please note it will be AI generated, then humanly reviewed and tested 👍 Let me know what you think.
References