Following up on his previous Content Security Policy and Laravel posts, Christoph Rumpel continues the series and looks at how to fix his site's integration with Turbolinks. Turbolinks makes it easier to load only partial portions of a site when links are clicked rather than reloading the entire page.

My last week was all about Content Security Policy (CSP). It was an emotional rollercoaster. I loved the concept of CSP and was happy that I managed to integrate it into my site. But then I noticed that caching and Turbolinks weren't working anymore because of the CSP nonces. I had to turn them off. Then yesterday, I found a way to use CSP nonces with the Laravel Response Caching package. I was super excited about it.

Still, Turbolinks weren't working.

He starts by describing the issue with the CSP policy and the Turbolinks tool, mostly that the nonces in the response header no longer match the ones in the embedded script tags of the new content. He ended up finding a solution in the hash-algorithm CSP directive. This allowed him to create a hash of the requested script and validate it without the need for a nonce. He includes the code changes to his previous Laravel Response Cache middleware setting this hash-algorithm directive on the script tag output.

Christoph Rumpel has posted a guide for the Laravel users out there that have wanted to implement a Content Security Policy (CSP) in their application. A CSP helps to prevent cross-site scripting issues by locking down the images, scripts, resources, etc. that can be used in your application.

Caching is lovely, and the Content Security Policy is incredible. But when you put them together... Let me show you the problems I encountered, and how I fixed them.

He starts by describing the setup he was working with and improvements he was making (using the Spatie Laravel ResponseCache package to improve the performance of his site). As a part of the refactor he decided to implement a CSP but had an issue where the nonces on the included scripts didn't change like they did in development. To resolve the issue he created a middleware that takes the response and, after calling the other middleware, append the header to the response instance. Full code for the solution is included in the post.

In a new post to his site Christoph Rumpel shares an introduction to the use of Content Security policies to prevent client-side security issues in your applications. While his examples are more Laravel-specific, the concepts can be applied to just about any framework or home-grown solution.

As more and more services get digital these days, security has become a significant aspect of every application. Especially when it comes to third-party code, it is tough to guarantee safety. But in general, XSS and Code Injection is a big problem these days. Content Security Policy provides another layer of security that helps to detect and protect different attacks. Today, I will introduce this concept and its main features, as well as show real-world examples.

He starts with a general look at web application security vulnerabilities and, more specifically, cross-site scripting issues. These are the ones that a Content Security Policy (CSP) can help prevent. He then covers the basics of the CSP header and gets into the implementation. In his example he sets up the addition of the CSP header as a middleware so that it's included on every request. With the default header all resources are blocked so he walks through the process of restoring access to the scripts, fonts and styles his blog needs to work correctly.

With the basics covered he then gets into a few more advanced features of CSP policies such as nonces for resource identification, iframe handling and the submission of forms. The post ends with a recommendation of the Laravel CSP package for use in Laravel applications. If you're looking for something more framework agnostic you might want to look into ParagonIE's CSP Builder library.