Improve default security with headers?

I’m wondering if perhaps Meteor should set certain headers like Cross-Origin-Opener-Policy to same-origin by default, etc, to make Meteor apps more tamper proof, as well as enabling cool features like SharedArrayBuffer by default.

It seems like a good idea to start with the most secure settings, then the docs can guide people how to relax settings.

Currently I do this manually by intercepting requests with WebApp.rawHandlers.

I also see there’s a BrowserPolicy API available to control some of these features, but I think the docs can be improved a bit to explain how each setting maps to specific headers. Plus, some headers, like Cross-Origin-Opener-Policy, are still not enabled by default (even if there may be a BrowserPolicy API for them, but I’m not sure from a skim of those docs).

Other frameworks default to same-origin for Cross-Origin-Opener-Policy, etc. For example the pgadmin4 setting and Django setting

The idea is n00bs making apps will be most protected by default, and people who learn security can strategically relax rules.

Thoughts?

1 Like

Coincidentally, a related topic: Content Security Policy in 3.4