browser-policy family of packages, part of
Webapp, lets you
set security-related policies that will be enforced by newer browsers. These
policies help you prevent and mitigate common attacks like cross-site scripting
When you add
browser-policy to your app, you get default configurations for
the HTTP headers X-Frame-Options and Content-Security-Policy. X-Frame-Options
tells the browser which websites are allowed to frame your app. You should only
let trusted websites frame your app, because malicious sites could harm your
users with clickjacking attacks.
tells the browser where your app can load content from, which encourages safe
practices and mitigates the damage of a cross-site-scripting attack.
browser-policy also provides functions for you to configure these policies if
the defaults are not suitable.
If you only want to use Content-Security-Policy or X-Frame-Options but not both,
you can add the individual packages
browser-policy-framing instead of
For most apps, we recommend that you take the following steps:
browser-policyto your app to enable a starter policy. With this starter policy, your app’s client code will be able to load content (images, scripts, fonts, etc.) only from its own origin, except that XMLHttpRequests and WebSocket connections can go to any origin. Further, your app’s client code will not be able to use functions such as
eval()that convert strings to code. Users’ browsers will only let your app be framed by web pages on the same origin as your app.
- You can use the functions described below to customize the policies. If your
<script>tags, we recommend that you modify the policy by calling
BrowserPolicy.content.disallowInlineScripts()in server code. This will result in one extra round trip when your app is loaded, but will help prevent cross-site scripting attacks by disabling all scripts except those loaded from a
Meteor determines the browser policy when the server starts up, so you should
BrowserPolicy functions on the server in top-level application code or in
BrowserPolicy functions cannot be used in client code.
By default, if you add
browser-policy-framing, only web
pages on the same origin as your app are allowed to frame your app. You can use
the following functions to modify this policy.
- Your app will never render inside a frame or iframe.
Your app will only render inside frames loaded by
origin. You can only call this function once with a single origin, and cannot use wildcards or specify multiple origins that are allowed to frame your app. (This is a limitation of the X-Frame-Options header.) Example values of
origininclude "http://example.com" and "https://foo.example.com". This value of the X-Frame-Options header is not yet supported in Chrome or Safari and will be ignored in those browsers. If you need Chrome and/or Safari support, or need to allow multiple domains to frame your application, you can use the frame-ancestors CSP option via the BrowserPolicy.content.allowFrameAncestorsOrigin() function
- This unsets the X-Frame-Options header, so that your app can be framed by any webpage.
You can use the functions in this section to control how different types of content can be loaded on your site.
- Disallows eval and related functions. Note: The default policy disallows eval, though for almost all Meteor apps it is enabled by the `dynamic-imports` package
- Allows inline style tags and style attributes. The default policy already allows inline styles.
- Disallows inline CSS.
Finally, you can configure a whitelist of allowed requests that various types of content can make. The following functions are defined for the content types script, object, image, media, font, frame, frame-ancestors, style, and connect.
Allows this type of content to be loaded from the given
originis a string and can include an optional scheme (such as
https), an optional wildcard at the beginning, and an optional port which can be a wildcard. Examples include
example.com:*. You can call these functions multiple times with different origins to specify a whitelist of allowed origins. Origins that don't specify a protocol will allow content over both HTTP and HTTPS: passing
example.comwill allow content from both
Allows this type of content to be loaded from a
- Allows this type of content to be loaded from the same origin as your app.
- Disallows this type of content on your app.
You can also set policies for all these types of content at once, using these functions:
For example, if you want to allow the
https://foo.com for all types of content but you want to disable
<object> tags, you can call
BrowserPolicy.content.allowOriginForAll("https://foo.com") followed by
Other examples of using the
BrowserPolicy.content.disallowFont()causes the browser to disallow all
BrowserPolicy.content.allowImageOrigin("https://example.com")allows images to have their
srcattributes point to images served from
BrowserPolicy.content.allowConnectOrigin("https://example.com")allows XMLHttpRequest and WebSocket connections to
BrowserPolicy.content.allowFrameOrigin("https://example.com")allows your site to load the origin
https://example.comin a frame or iframe. The
BrowserPolicy.framingAPI allows you to control which sites can frame your site, while
BrowserPolicy.content.allowFrameOriginallows you to control which sites can be loaded inside frames on your site.
browser-policy-content to your app also tells certain
browsers to avoid sniffing content types away from the declared type
header. To re-enable content sniffing, you can call