CORS, Content Security Policy and Access Control for SAFE sites

Or. If you are using webpack (and their dev-server) you can transparent-proxy /0.5 through to the launcher and all is good (as ‘self’ is listed), like so. Then you can run it against local development or even live safenet…

This is much better and emulates the final behavior of the network closest.

Would there be interest in us providing a minimal proxy-ing webpack setup for people to start their development with?


The problem isn’t on this side, but the other way round. There was a lengthy discussion, which lead to the CSP rules in the first place. I recommend to read up on that, but the gist is: Allowing any not *.safenet domain means potential leakage of information – like tracking tools and alike. And although the potential problem with localhost itself is small (like, the tracker would need to have either installed something on the computer or somehow route it through localhost), I’d consider whitelisting it bad practice – especially as it is only about development convenience. This is where security bugs come from: developer convenience (or why do you think all router have a super simple default password).

We should not compromise on this, considering there are clean and easy ways (as shown right before) to provide a smooth development experience without touching the good integrity of the CSP rules.

1 Like

Fair enough, I don’t really mind how it’s done, but I think it would be good to keep the amount of hoop someone needs to go through to start coding as little as possible.

And it should be done quickly, with the new API coming up and the tutorials on their way we need this ASAP.


I whole heartily agree!

1 Like

Under Windows 10 IE11 en Edge can’t be bothered to prevent access when doing it this way:

<!-- -->
<!DOCTYPE html>
    <title>Simple Safe API example</title>
    <iframe sandbox="allow-same-origin allow-scripts allow-popups allow-forms"
            style="border:0; height:300px; width:100%;">

This is “index.html”, opening it from a local webserver loads “simple_safe.html” containing @DavidMtl’s code and localhost:8100 as endpoint.

Also works from “simple_safe.html” opened as a local file if you remove his ‘localstorage’ lines.

FF and Chrome do complain. As the MS twin set should but does not.

1 Like

IE doesn’t understand default CSP (unless you do the deprecated prefix, wondering if we might want to provide that) and Edge only from version 12 – see – which version are you running?

But even then Edge only supports CSP-1.0 and the child-src (which should prevent this here) is only part of CSP-2.0 (I refer to the URL from before). I suppose we should also add the already deprecated frame-src 'self'. I’m wondering though why the default-src doesn’t catch it here.

Is there any way you, @JBishop, can confirm it blocks with that tag added?



Header add Content-Security-Policy "default-src 'self'"

Stopped and started the server and indeed, blocked:
CSP14312: Resource violated directive 'default-src 'self'' in Content-Security-Policy: http://localhost:8100/auth. Resource will be blocked.

Took that CSP line out again, stopped and started and was allowed to approach Safe Launcher again. This was in Edge 14 (Microsoft Edge 38.14393.0.0)

Odd, default-src 'self' is already in the proxy.

Just to clarify, the setup is: you are hosting a file (the one you posted), which has an iframe to a file hosted on safenet/served through the safenet proxy?

Wait. That doesn’t appear to be the case though. Only that second file (from within the iframe) is then going through the launcher, am I correct? Well in that case, that’s the first place the CSP is currently returned and thus the other pages before aren’t protected by it. It’s rather odd that FF and Chrome block here, they shouldn’t.

But that isn’t realistic conditions: on safenetwork also your initial html and the iframed-html page would be served with CSP headers, thus eliminating the problem you are talking about. This only happens in the specific development setup you are having at the moment.

Either way, I feel even stronger about streamlining this now. The pages of your local system should be served with the same CSP-headers to create realistic conditions and avoid finding out about problems like these only after you deployed.

I agree, but also with the option to turn CSP off with a debug setting, not something directed at everyday users (like the difficult to access CORS control variable in Firefox etc.)

I’m now trying to locally run a safe web app and I’m running into this issue with launcher v0.10.0.
I tried with a local launcher as well, with “npm run dev” but it still doesn’t work. Is there a way to overcome this with the launcher? or what are my options?
I’m using safe-js, and either with or without the polyfill I see the same result.

1 Like

CSP is disabled on latest launchers, because there is no proxy anymore.

I think there might be a different problem, but it gets exposed as an “CSP” problem - dunno why, but the browser does that sometimes. Take a close look to the actual error message in the object in the console and the http request.

Just to check: have you “disabled web security on new tabs” and opened a new tab?

If not that would cause this.

EDIT: Oh, you’ll need to be running a local Beaker too, with NODE_ENV=devel or you won’t get that menu option!


Thanks a lot @ben and @happybeing!
It worked after “disabling the web security for new tabs” as suggested by @happybeing (I’m sorry I wasn’t aware of this option :blush:). Although, I was able to do it with an AppImage of Beaker (v0.4.0-5).


Although, I was able to do it with an AppImage of Beaker (v0.4.0-5).

That sounds like a bug! @joshuef?

Huh? I’m confused… It works or?

If not, please try with the latest version (0.4.2 stable) Releases · joshuef/beaker · GitHub , dev mode with NODE_ENV=development as @happybeing noted.

Let me know how you get on!

1 Like

My understanding is that @happybeing was suggesting this option shouldn’t be available when running the AppImage but only if you build it with NODE_ENV=devel.

Aha. Yes that makes sense :smiley: Totally read this wrong.

@happybeing this is only available with the AppImage? Or all linux builds?

Ask @bochaco - I haven’t tried it. I’m only using source!

1 Like

I’ve been using the AppImage v0.4.0-5 x64 only, and it works, i.e. I’m able to use safe-js polyfill to connect to the Launcher, running my app locally with nodejs.

As an aside comment, for those devs out there, I also managed to do the same running my app within Electron.