Back in November I posted a surprisingly popular first part in a series of articles on Hardening Website Security (link<\/a>). Since then I have been analysing Content Security Report (CSP) violation false-positives and expanding my knowledge on the subject, and thought an update was due.<\/p>\n\n\n\n If you haven’t yet, I recommend reading the original article first here<\/a>.<\/p>\n\n\n\n Before we get back into the Content Security Policy, I thought it would be worthwhile adding another header to the list: Feature-Policy.<\/p>\n\n\n\n The Feature Policy behaves much like a Content Security Policy, in that it is used for restricting or unrestricting functionality on a website. However, where a CSP is used to control security around resources, a feature policy is used to control\u2026 well\u2026 features.<\/p>\n\n\n\n Basically, the Feature Policy is used to communicate with the client’s web browser to let it know what features the website is going to use (if any), and what sources are allowable for it.<\/p>\n\n\n\n Let’s take “camera” for example. If your website doesn’t have any need to access the client’s webcam then setting this to ‘none<\/em>‘ is like telling the browser: “We don’t want access to your camera, if you get a request then just block it.<\/em>“<\/p>\n\n\n\n Alternatively, if you do<\/em> use the camera, then setting it to ‘self<\/em>‘ tells the browser to expect this request if it comes through. This has the added benefit of exerting extra control when using third party libraries so you are saying “This website may need access to your camera, but if a request comes from anywhere else, block it.<\/em>“.<\/p>\n\n\n\n You can find the full list of features in Chromium’s feature policy source code<\/a>, but the main ones are:<\/p>\n\n\n\nFeature Policy<\/h2>\n\n\n\n
About the Feature Policy<\/h3>\n\n\n\n
Example<\/h3>\n\n\n\n