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.

In a recent post to his site Aidan Woods shares information (and code) related to the use of secure headers in PHP applications. He's even created a package to help make it easier to drop them into a new or existing project without too much trouble.

Recently I've been working on a drop in class to manage certain "Secure Headers" in PHP. By "Secure Headers", I'm of course talking about those mentioned in the OWASP Secure Headers Project. The project, SecureHeaders is available on GitHub.

He starts by covering why he created the library and what it can help you with including making things like a CSP policy easier to maintain. The article goes on to talk about the Content-Security-Policy header is and what kind of prevention it applies. He also shares how the package displays errors, modifies cookies to secure them (HTTPOnly and Secure flags) as well as provide a "safe mode" that "place an upper limit on things like HSTS and HPKP, and remove flags like includeSubDomains or preload until the header is manually added as a safe mode exception, or safe mode is disabled."

From DashExamples.com there's a quick post on how you can set up your application to notify you on content security policy violations and store them back on he server side for later review.

When somebody violates your CSP rules, there is a great feature that can setup for supporting browsers to send back the violations to your server to be saved, processed or whatever. This is a great feature because you can stop a possibly malicious piece of code from executing and learn which scripts may have vulnerabilities in your code.

The reports as delivered by the browser back to your server according to your site's policy setup. They're sent back as a JSON string that is easily parsed and stored. The post shows you a sample database table structure (storing things like request, headers, blocked location and IP address) and the PHP to handle the incoming post. For more about the CSP reports, see Mozilla's example on their Developer section.