
My beloved Ruby on Rails framework offers [a convenient way](https://guides.rubyonrails.org/security.html#content-security-policy-header) for managing the content security policy (CSP). Unfortunately, it's disabled by default. But then, even when we turn it on, the default settings are [less than ideal](https://www.csphero.com/blog/safest-content-security-policy).

No worries! In this article, we will configure CSP in Rails, adopt best practices, and ensure a more secure environment for your web application.

## How to enable CSP?

If you create a new Rails application (at least in Rails 7), CSP is turned off by default. To enable it, we must uncomment the `config/initializers/content_security_policy.rb` and restart the server.

The important part looks like this. Note I added comments to explain each line.

```ruby
config.content_security_policy do |policy|
  # fallback allows to load everything from any website
  # as long as it's https or our own domain.
  policy.default_src :self, :https

  # fonts can be loaded from any https websites,
  # or using data:
  policy.font_src    :self, :https, :data

  # same for images
  policy.img_src     :self, :https, :data

  # completely forbid <object>, <embed>,
  # and other legacy tags
  policy.object_src  :none

  # scripts and styles allowed to load from
  # any HTTPS website
  policy.script_src  :self, :https
  policy.style_src   :self, :https
end
```

It's alright. But it's far from ideal. They allow you to load everything from any website as long as it's HTTPS.

It's also worth noting that CSP will NOT allow any inline scripts in this default configuration. You'll have to put every script and style in its own file, and even specifying inline handlers like `<button onclick="...">` is forbidden.

There's still a way to securely allow inline scripts - see the section about nonces.

## Making it more secure

What if we want to get serious about CSP? First, it's worth understanding that `:https` directive is far too permissive. If you know exactly that all your scripts are coming from your own domain, it's better to make it stricter:

```ruby
policy.script_src  :self
```

If some of your scripts or styles are loaded from third-party websites, specify those domains.

```ruby
policy.style_src  :self, https://maxcdn.bootstrapcdn.com
```

It could be a bit trickier with fonts; see how to [set up Google Fonts in this article](https://www.csphero.com/blog/content-security-policy-for-google-fonts).

To conclude, try to remove as many of those `:https` as possible and replace them with specific domains.

We can make it more secure in more ways, but it depends on your specific needs. Look at [this article](https://www.csphero.com/blog/safest-content-security-policy) for more details.

## Allowing inline JavaScripts with a nonce

If you need to use an inline script but don't want to sacrifice security - you can still do this.

The [CSP specification](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src) allows using so-called nonces to make the inline scripts which are "safe".

Basically, a nonce is a random string you can put in the CSP config.

```ruby
policy.script_src  :self, 'nonce-abc123'
```

Then, you specify it with the script.

```ruby
<script nonce="abc123">
  alert("Hooray, I'm allowed!")
</script>
```

But with Rails, it becomes even more convenient. You don't need to worry about generating those tokens, Rails will do this for you.

To make it work, you need to add those lines (or uncomment, as they are already present in the file):

```ruby
# Generate session nonces for permitted importmap and inline scripts
config.content_security_policy_nonce_generator = ->(request) { request.session.id.to_s }
config.content_security_policy_nonce_directives = %w(script-src)
```

The default strategy is to use the session ID for every script (meaning that all your inline scripts will share the same token), or you can use a random one like this:

```ruby
config.content_security_policy_nonce_generator = -> request { SecureRandom.base64(16) }
```

I can't think of a single reason why one of the strategies would be more secure or less secure than the other. So feel free to use whatever is convenient.

Just don't forget to enable nonce for every inline script:

```ruby
<%= javascript_tag nonce: true do -%>
  alert('Hello, World!');
<% end -%>
```

## How to add a report url?

Finally, if you want to add a reporting url, that's also very easy with Rails. Just add this line into the configuration:

```ruby
policy.report_uri "<your reporting url>"
```

For example, if you use [CSPHero](https://www.csphero.com/) to collect and make sense of the CSP reports, it would look something like

```ruby
policy.report_uri "https://app.csphero.com/report/P2viPU61"
```

## Conclussion

As you can see, the magnificent Rails framework makes our life much easier with built-in support for CSP. I only wish it was enabled by default and use a bit more sane defaults. But I hope they will fix it in the upcoming releases.


Rails ships with CSP support but it's off by default. Learn how to enable it in content_security_policy.rb, set secure directives, use nonces, and handle report-only mode.

Collect and manage violation reports from your content security policy. A real-time, comprehensive solution for maintaining the integrity of your website content.

CSP Hero

Content Security Policy in Rails — Enable, Configure & Deploy CSP


Surprisingly, `defaults-src 'self'` is not the safest CSP policy. That's mostly because there are directives that don't fall back to `default-src` by default and are permissive when not specified.

Then what CSP policy is the most secure?

**TL;DR**: The most secure Content-Security-Policy which should work for most websites is:

```
default-src 'self'; media-src 'none'; child-src 'none'; frame-src 'none'; object-src: 'none'; connect-src 'none'; manifest-src 'none'; frame-ancestors: 'none'; base-uri 'none'; form-action 'self'
```

Now let's see why.

## Getting started

We start with the most straightforward policy we can think of, and that is:

```
default-src 'self';
```

This policy is already powerful enough.

1. It restricts all the resources (scripts, styles, images, etc.) only to allow being loaded from the current domain. Even subdomains are not allowed. So if our main domain is `mydomain.org`, it won't be able to load scripts from `cdn.mydomain.org`. This subdomain must be specifically included in the policy (e.g., `default-src 'self' https://cdn.mydomain.org`).

2. Out of the box, it disallows inline javascript and `eval`. This, by itself, is a huge security booster because it [protects us from XSS injections](https://www.csphero.com/blog/fixing-unsafe-inline).

Note that technically speaking, we can make the policy even stronger by switching `default-src 'none'`. But practically, it makes little sense since. We probably want to load at least some resources like styles and fonts, even if our page doesn't use JavaScript at all.

## Directives that fall back to default-src

Since we know what kind of resources we use on the website, typically, of course, `scripts`, `styles`, `images`, and `fonts` are all required to load, but sometimes some of them don't.

For example, if you don't use custom fonts and images (a text-only blog?), you should go ahead and disable those.

```
default-src 'self'; img-src 'none'; font-src 'none';
```

For the sake of this article, we won't disallow those resources since 99% of websites need those.

## Disallowing less-popular resources

The [media-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/media-src) directive is used to restrict the loading of resources used in `<audio>`, `<video>`, and `<track>`. Chances are, you don't have those on your website. Let's go ahead and disable them.

```
default-src 'self'; media-src 'none';
```

The same goes for [child-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/child-src) (web workers and iframes) and `frame-src` (iframes, falls back to `child-src`).

```
default-src 'self'; media-src 'none'; child-src 'none'; frame-src 'none';
```

The [worker-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src) directive governs web workers and falls back first to `child-src`, then to `script-src`, and finally to `default-src`. Since we already included `child-src 'none'`, we don't need to add it specifically. But if you use web workers, you can add it.

Does anyone still uses [Flash](https://en.wikipedia.org/wiki/Adobe_Flash) or [Java Applets](https://en.wikipedia.org/wiki/Java_applet). Probably not, so let's disable [object-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/object-src).

```
default-src 'self'; media-src 'none'; child-src 'none'; frame-src 'none'; object-src: 'none'
```

In case you don't use ajax (but also `fetch`, websockets, and some other) loading, you might want also to turn off [connect-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src). It does fall back to `default-src`, which is `'self'` in our case. Let's assume we don't.

```
default-src 'self'; media-src 'none'; child-src 'none'; frame-src 'none'; object-src: 'none'; connect-src 'none'
```

Finally, assuming you don't need a [manifest](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json), you should probably disable [manifest-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/manifest-src) as well.

```
default-src 'self'; media-src 'none'; child-src 'none'; frame-src 'none'; object-src: 'none'; connect-src 'none'; manifest-src 'none'
```

Plenty of websites include a manifest, so instead of `manifest-src 'none'`, we can set it to `manifest-src 'self'`.

## Directives that don't fallback to default-src

Some of the directives don't fall back to `default-src`, and if we don't specify them, the browser will allow anything.

For example, did you know that anyone can include your website inside an iframe for whatever malicious reason on their website? We can disallow it with [frame-ancestors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors).

```
default-src 'self'; media-src 'none'; child-src 'none'; frame-src 'none'; object-src: 'none'; connect-src 'none'; manifest-src 'none'; frame-ancestors: 'none'
```

The [base-url](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/base-uri) directive restricts what can be set in [base](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base) tag. If an attacker adds such a tag on your page, he can practically [redirect all links to a malicious website](https://www.invicti.com/web-vulnerability-scanner/vulnerabilities/base-tag-hijacking/). It's a good idea to set it to either `'self' or `'none'`.

```
default-src 'self'; media-src 'none'; child-src 'none'; frame-src 'none'; object-src: 'none'; connect-src 'none'; manifest-src 'none'; frame-ancestors: 'none'; base-uri 'none';
```

Finally, with [form-action](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/form-action), we can control URLs that can be used as the target of form submissions. Similarly, it doesn't fall back to `default-src`, allowing any URLs by default. That's why it's important to restrict it to `'self'` (or `'none'` in case you don't have any form submissions on your website).

```
default-src 'self'; media-src 'none'; child-src 'none'; frame-src 'none'; object-src: 'none'; connect-src 'none'; manifest-src 'none'; frame-ancestors: 'none'; base-uri 'none'; form-action 'self'
```

## Reporting

With Content-Security-Policy, we can set a reporting URL, which will serve as a collector for all violation reports. If something tries to violate any of the rules, the browser will send a JSON report to the specified URL. It's crucial to collect such reports and analyze them for possible vulnerabilities or mistakes.

For example, it might look like this with [CSP Hero](https://www.csphero.com/).

```
default-src 'self'; media-src 'none'; child-src 'none'; frame-src 'none'; object-src: 'none'; connect-src 'none'; manifest-src 'none'; frame-ancestors: 'none'; base-uri 'none'; form-action 'self'; report-uri https://app.csphero.com/report/Wab8kRBH
```

## Wrap up

Turns out, `default-src 'self'` doesn't necessarily get us the most secure CSP. Disallowing resources like `media-src`, `child-src`, `frame-src`, `object-src`, `connect-src`, and `manifest-src` can significantly elevate security, especially if these resources aren't required.

Furthermore, directives like `frame-ancestors`, `base-uri`, and `form-action` can provide a strong line of defense against iframe misuse, base tag hijacking, and unauthorized form submissions, respectively. The important part is that they are allowing and don't fall back to default-src. That's why they need to be included and restricted specifically.
 


default-src 'self' isn't the safest CSP. Learn which directives you're missing, build the most secure content security policy step by step, and copy a production-ready header.

The Safest Content Security Policy — Build a Secure CSP from Scratch


**TL;DR**: Avoid using `unsafe-inline`. Instead, move inline scripts into separate files, or utilize the hash/nonce mechanisms.

The [CSP (content security policy)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) is a low-hanging fruit - an easy way to improve security significantly.

To fully benefit from CSP, it's better to adhere to the default rules and refrain from allowing 'unsafe-inline'. It is called "unsafe" for a reason!

## What are inline scripts?

What are inline scripts? It's any JavaScript appearing directly in the body of your HTML page.

For instance, inline event handlers look like this:

```html
<button onclick="alert('Button clicked!')">Click Me!</button>
```

Or, here's a script that changes color upon mouseover:

```html
<p onmouseover="this.style.color='red'">Hover over me!</p>
```

Even the scripts inside the `<script>` tag are considered "inline" because they are within the HTML bode of your page:

```html
<script>
document.addEventListener("load", () => {
  // more code
})
</script>
```

## Wrong way to fix the error

What if you encounter an error like this?

```
Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash, or a nonce ('nonce-...') is required to enable inline execution.
```

A common mistake many developers make is to add the ['unsafe-inline'](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_inline_script directive).

```
default-src 'self'; script-src 'self' 'unsafe-inline'
```

Yes, it's an easy thing to do, but it's not a real solution. It doesn't fix the problem but simply hides it and suppresses the warning.

## Why block inline scripts?

So, why is allowing inline scripts is a bad idea?

The main purpose of CSP is to **mitigate [XSS Attacks](https://owasp.org/www-community/attacks/xss/)**. If 'unsafe-inline' is enabled, malicious inline scripts injected into the webpage could run, leading to security threats.

The whole idea of using CSP is undermined.

## Move JavaScripts into its own files

The best solution in terms of security and maintainability is to move any inline JavaScript into its files.

For example, use `addEventListener`:

```javascript
document.addEventListener('click', () => alert("Button clicked!"))
```

## Using hash

But what if you really need to use inline scripts?

The Content Security Policy allows specifying [a hash](https://content-security-policy.com/hash/) or [a nonce](https://content-security-policy.com/nonce/) that uniquely identify the scripts, thus making the browser allow those script only and refusing all the others.

Here's an example of using a hash

Imagine you have an inline script:

```javascript
alert("Hello, world!")
```

We can calculate its hash using a simple CLI command:

```
echo -n "alert('Hello, CSP!');" | openssl dgst -sha256 -binary | openssl base64
#=> 01RsA/xEak42pBoMWnMM/OfOi29OmSdMxC0UBetjy/Q=
```

Now simply include that in the content security policy:

```
default-src 'self'; script-src 'self' 'sha256-01RsA/xEak42pBoMWnMM/OfOi29OmSdMxC0UBetjy/Q='
```

And then, that script will be executed by the browser.

## Using a nonce

The other way, which is somewhat similar, is to use a nonce.

A nonce is any unique string that identifies the script. It needs to be specified both within the CSP and in the script itself.

For example,

```
default-src 'self'; script-src 'self' 'nonce-myallowedscript'
```

And then the script:

```
<script nonce="myallowedscript">
  alert('Hello, world.');
</script>
```

## What's next

Note that both hash and nonce methods, while relatively simple, still add some overhead. For example, you need to update the hash every time the script is changed, etc.

So the best solution is not to use inline scripts at all. If you have some - move them into their own files. And then make sure to only allow loading script from your own domain.

To read more about the topic, [MDN is always](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src) a great source.


Step-by-step guide to removing 'unsafe-inline' from script-src and style-src. Use nonces, hashes, or external files to keep your CSP secure without breaking your site.

How to Fix unsafe-inline in Your Content Security Policy


**TL;DR:** Use the following snippet to setup CSP for Google
Fonts:

```
default-src 'self';
style-src 'self' https://fonts.googleapis.com;
font-src https://fonts.gstatic.com
```

## What is CSP?

[Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) allows you to define a set of rules that control what resources are being loaded on your website. This is a great way to prevent malicious scripts from being loaded on your website, and to prevent XSS attacks.

Sometimes it can stand in your way.
Does that look familiar?

```
Refused to load the stylesheet 'https://fonts.googleapis.com/css2?...' because it violates the following Content Security Policy directive: "style-src 'self'".
Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.
```

How to fix such an error?

## Fixing Google Fonts issues

Let's start with the simplest CSP.

```
default-src 'self';
```

As you probably know, the [default-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/default-src) directive serves as a fallback for a bunch of other directives.

This CSP snippet prevents any resource being loaded from any host other than itself. But Google Fonts are hosted on a different domain, so we need to specifically allow this domain for stylesheets.

```
default-src 'self'; style-src 'self' https://fonts.googleapis.com
```

OK, now we get the next error.

```
It has refused to load the font 'https://fonts.gstatic.com/s/...' because it violates the following Content Security Policy directive: "default-src 'self' https://fonts.googleapis.com". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.
```

It happens because we only allowed the browser to load the CSS file. But that stylesheet includes references to the actual font files. When the browser tries to download them, it gets refused.

Let's add it as well.

```
default-src 'self'; style-src 'self' https://fonts.googleapis.com; font-src https://fonts.gstatic.com
```

That's it!

## What's next?

If you want to learn about CSP - [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) is a great resource.

If you need to track and analyze CSP reports, try [CSP Hero](https://www.csphero.com/).


Copy-paste CSP directives for Google Fonts. Set style-src fonts.googleapis.com and font-src fonts.gstatic.com to load web fonts without breaking your content security policy.

Collect & Analyze CSP Violation Reports in Real-Time

Why collect CSP reports?

Monitor Compliance

Identify Vulnerabilities

Detect Attacks

Refine Policies

Pricing

Regular

Custom

From the Blog

Free Tools