Shieldwall: Security Headers, CSP, CSRF

[boreal kestrel]

Middleware library to secure apps

https://github.com/atilafassina/shieldwall

full thing:

import { createMiddleware } from "@solidjs/start/middleware";
import { securityHeaders, csp, csrf } from "shieldwall/start";
import { SELF } from "shieldwall/start/csp";

export default createMiddleware({
  onRequest: [
    csrf,
    securityHeaders(),
    csp({ extend: "dev_hmr_friendly" }, config: { withNonce: false }),
    csp({
      extend: "production_basic",
          config: {
        withNonce: true,
        reportOnly: true,
        value: {
        "frame-src": [SELF],
        },
        },
    }),
  ],
});

[fiery flume]

shieldwall is a bad ass name

[boreal kestrel]

it is!! I can't believe it was free to take!

[edgy hawk]

@boreal kestrel does this work for SSG? (no server runtime)

[boreal kestrel]

you need the middleware running, so no.

Unless you mean prerendering all routes - but I still consider that SSR

[edgy hawk]

yeah prerendered

but no dynamic ssr

[frozen ferry]

@boreal kestrel where does shieldwall decide which csp should be used?

[boreal kestrel]

each one of those methods is a standalone middleware - the middlewares will create the headers and attach them to the request object.

so if you apply the same header twice, the last one will prevail... in the snippet above, one is adding Content-Security-Policy-Report-Only and the other is adding Content-Security-Policy - so both will attach.

[frozen ferry]

ahh ic, idk how csp works haha

[boreal kestrel]

same happens with the nonce, the way it works is by adding the nonce to the event locals, so if you the second one will override the first one... if the blocking CSP is the first - nothing will run

[boreal kestrel]

it's a declarative header that will tell the browser which resources are ok to run on that tab instance.
This way you can allow-list domains and block all the rest for external resources... block inline or eval, etc...

you can do that per feature (iframes, styles, script, connect) and have a catchall (default-src)

[frozen ferry]

should reportOnly on the production one be dependent on isDev?

[boreal kestrel]

I don't think so... the Dev-specific CSP is to allow inline styles, script, and websockets for HMR to work

report-only is when you want to add new rules but you don't want to risk nuking your entire UX by making it too aggressive

so report-only will flag anything that would otherwise be blocked and send to your observability system

it's specially useful because often browser extensions get blocked by CSPs

[frozen ferry]

so with the above setup only the dev csp is actually enforced?

[boreal kestrel]

so you can get a few false-positives, or - if your users depend on certain extensions - you can make sure it's strict in the right places only

[boreal kestrel]

yep... the other will flag in the browser console.log everything that the CSP would block if not reporting only

and, if you pass the report-uri directive, it will send the report

[frozen ferry]

ok that makes more sense, ty

@boreal kestrel might it make more sense for CSP to be handled in entry-server instead of middleware, since they only need to be applied to html?

middleware is more consistent but i don't think we can be as fancy with automating it in solidbase

[boreal kestrel]

the CSP is an HTTP header

you can have it as a <meta> but it's less powerful

[frozen ferry]

yeah attach it as a header in entry-server

[boreal kestrel]

like it doesn't support nonce

[boreal kestrel]

ah... yeah, that would be possible

[frozen ferry]

interesting

[boreal kestrel]

internally, I have a buildCSP method that would "just work" in that case if I updated it

actually, come to think of it, you can call csp()(fetchEvent) and that would also work already

[frozen ferry]

lmao true

[hollow knot]

Can this pretty much just be added to Start projects? (I'm looking at adding some more integrations back into the CLI since the rewrite and this look awesome!!)