fix: remove permissive CDN content security sources #27
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/w10-csp-origins"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes W10 from bugs.md.
Drops unpkg, jsDelivr and cdnjs from
script-srcand unpkg fromstyle-src. Nothing loads scripts from those CDNs at runtime — Leaflet, Chart.js and plugins ship from the local vendor bundle (scripts/build-vendor-bundle.jsfetches them at build time), so the allow-list only offered arbitrary-npm-package script execution to any future HTML-injection bug in packet-rendering templates. The moduledoc now states why the CDNs are absent and whystyle-src 'unsafe-inline'remains (runtime-computed inline style attributes for symbol sprites, chart sizing and marker positioning cannot be hashed; nonce-splitting needs conn access in LiveView components and is left as a documented follow-up).Verification: focused CSP tests passed (12) with a new negative assertion for all three CDNs, full suite passed (2236),
mix credo --strict, commit hooks including Dialyzer, and a live dev-server smoke confirmed the served header contains no CDN origins.🤖 Skippy PR review
1 finding — none blocking.
lib/aprsme_web/plugs/content_security_policy.ex:33Reviewed
8debe9eda2f3. Commentskippy reviewto re-run.@ -25,3 +33,1 @@@external_style_sources ["https://unpkg.com""https://js.sentry-cdn.com"🔵 Suggestion — js.sentry-cdn.com is dead weight too — nothing in the repo uses Sentry
The argument that retired unpkg/jsDelivr/cdnjs applies to this entry: a case-insensitive
grep -r sentryover the tree at8debe9ereturns no Sentry at all — nosentrydep inmix.exs/mix.lock, noSentry.initinassets/js, no script tag inlayouts/root.html.heex, nothing inconfig/,rel/ork8s/. The only hits are this plug and its test, soscript-srcstill allow-lists a third-party script host for an integration that does not exist, and the new moduledoc bullet list still advertises "Sentry error tracking". If the browser SDK is coming back, one line here saying so is enough; if not, drop this entry together with the twoconnect-srcSentry origins (https://*.ingest.sentry.io,https://*.sentry.io), which are equally unexercised. Not blocking — nothing fails today, it is just residual surface on a PR whose whole point is removing residual surface.Resolved 1 of 1 earlier findings — the Sentry
script-srchost and both*.sentry.ioconnect-srcorigins are gone fromcontent_security_policy.ex, the moduledoc bullet was dropped, and the test now asserts all three absent.Nothing new in
8debe9e..6104ae7— the follow-on commit only removes those origins and reworks the tests accordingly. 0 still open.