Related to this other post about content security policies in PHP sites, DashExamples.com has a quick new post about what you'll need to add to your application to implement a policy of your own.

Content Security Policy(CSP) is a mechanism in the browser that restricts what content will be requested and run by the browser. CSP does this by passing in a specific response header that tells the browser what resources (images, javascript, css, frames, etc) can be requested and accepted to execute. There are multiple ways to setup CSP for your web site, you can use your web server configuration like I showed in a previous example or use a dynamic scripting language like PHP.

What it really boils down to is setting a header, either X-Content-Security-Policy or X-Content-Security-Policy-Report-Only, to tell the browser what security policy to use and how to honor it. You can find out more about content security policies from this page on the Mozilla wiki. CSPs allow you to define how your site's content interacts and help to prevent issues like XSS and data injection.

Jani Hartikainen has written up a new post for his blog looking at how to combine multiple password validation methods inside of a single application.

If your application is well thought out, you would not want to save any data that isn't valid. So what do you do, when you need different validation schemes, say for passwords, depending on some special case? [...] There is a better approach: Using a "policy" - Policies can be used for other things than this too, but let's look at how to use a policy for managing password validation.

He sets up an example scenario where the user sets an invalid and valid password and shows how policies for password validation (regular expression matches and other validation techniques) can provide a simple way to ensure the user has entered the right information.

In an effort to keep things a bit more secure (after finding out about this) the symfony team has officially released their own security policy to help prevent issues like that in the future.

You may be wondering why it has been taking us such a long time to react. Here's the main reason: we had not a very strong security alert reporting and qualifying process. This has been fixed recently. So as of now, if you find a security bug in symfony, please send an email to security at symfony-project.com, with as much details as you can and ideally a patch if you can provide one.

The wiki has a whole section on how to report security issues to get them to the right place.