Edit Page

Content security policy

Content Security Policy (CSP) is a W3C specification for instructing the client browser as to which location and/or which type of resources are allowed to be loaded. This spec uses "directives" to define loading behaviors for target resource types. Directives can be specified using HTTP response headers or HTML <meta> tags.

Enabling CSP

Using lusca

lusca is open-source under the Apache license

First:

# In your sails app
npm install lusca --save --save-exact

Then add csp in config/http.js:

// ...

  csp: require('lusca').csp({
    policy: {
      'default-src': '*'
    }
  }),

  // ...

  order: [
    // ...
    'csp',
    // ...
  ]

Supported directives

To give you an idea how this works, here's a snapshot of supported CSP directives, as of 2017:

Directive
default-src Loading policy for all resources type in case a resource type dedicated directive is not defined (fallback)
script-src Defines which scripts the protected resource can execute
object-src Defines from where the protected resource can load plugins
style-src Defines which styles (CSS) the user applies to the protected resource
img-src Defines from where the protected resource can load images
media-src Defines from where the protected resource can load video and audio
frame-src Defines from where the protected resource can embed frames
font-src Defines from where the protected resource can load fonts
connect-src Defines which URIs the protected resource can load using script interfaces
form-action Defines which URIs can be used as the action of HTML form elements
sandbox Specifies an HTML sandbox policy that the user agent applies to the protected resource
script-nonce Defines script execution by requiring the presence of the specified nonce on script elements
plugin-types Defines the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded
reflected-xss Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header
report-uri Specifies a URI to which the user agent sends reports about policy violation

For more information, see the W3C CSP Spec.

Browser compatibility

Different CSP response headers are supported by different browsers. For example, Content-Security-Policy is the W3C standard, but various versions of Chrome, Firefox, and IE use X-Content-Security-Policy or X-WebKit-CSP. For the latest information on browser support, see OWasp.

Additional Resources

  • Content Security Policy (OWasp)
  • Learn more about installing HTTP middleware in Concepts > Middleware.

Is something missing?

If you notice something we've missed or could be improved on, please follow this link and submit a pull request to the sails repo. Once we merge it, the changes will be reflected on the website the next time it is deployed.

Sails logo
  • Home
  • Get started
  • Support
  • Documentation
  • Documentation

For a better experience on sailsjs.com, update your browser.

Check out the full Sailsconf 2023 playlist on Youtube

Tweet Follow @sailsjs

Documentation

Reference Concepts App structure | Upgrading Contribution guide | Tutorials More

Concepts

  • Actions and controllers
    • Generating actions and controllers
    • Routing to actions
  • Assets
    • Default tasks
    • Disabling Grunt
    • Task automation
  • Blueprints
    • Blueprint actions
    • Blueprint routes
  • Configuration
    • The local.js file
    • Using `.sailsrc` files
  • Deployment
    • FAQ
    • Hosting
    • Scaling
  • E-commerce
  • Extending Sails
    • Adapters
      • Available adapters
      • Custom adapters
    • Custom responses
      • Adding a custom response
    • Generators
      • Available generators
      • Custom generators
    • Hooks
      • Available hooks
      • Events
      • Hook specification
        • .configure
        • .defaults
        • .initialize()
        • .registerActions()
        • .routes
      • Installable hooks
      • Project hooks
      • Using hooks
  • File uploads
    • Uploading to GridFS
    • Uploading to S3
  • Globals
    • Disabling globals
  • Helpers
    • Example helper
  • Internationalization
    • Locales
    • Translating dynamic content
  • Logging
    • Custom log messages
  • Middleware
    • Conventional defaults
  • Models and ORM
    • Associations
      • Many-to-many
      • One way association
      • One-to-many
      • One-to-one
      • Reflexive associations
      • Through associations
    • Attributes
    • Errors
    • Lifecycle callbacks
    • Model settings
    • Models
    • Query language
    • Records
    • Standalone Waterline usage
    • Validations
  • Policies
    • Access Control and Permissions
  • Programmatic usage
    • Tips and tricks
  • Realtime
    • Multi-server environments
    • On the client
    • On the server
  • Routes
    • Custom routes
    • URL slugs
  • Security
    • Clickjacking
    • Content security policy
    • CORS
    • CSRF
    • DDOS
    • P3P
    • Socket hijacking
    • Strict Transport Security
    • XSS
  • Services
  • Sessions
  • Shell scripts
  • Testing
  • Views
    • Layouts
    • Locals
    • Partials
    • View engines

Built with Love

The Sails framework is built by a web & mobile shop in Austin, TX, with the help of our contributors. We created Sails in 2012 to assist us on Node.js projects. Naturally we open-sourced it. We hope it makes your life a little bit easier!

Sails:
  • What is Sails?
  • Community
  • News
  • For business
About:
  • Our company
  • Security
  • Legal
  • Logos/artwork
Help:
  • Get started
  • Documentation
  • Docs
  • Contribute
  • Take a class

© 2012-2023 The Sails Company. 
The Sails framework is free and open-source under the MIT License. 
Illustrations by Edamame.