Technology has evolved to the point where it has revolutionised communications and changed our everyday life. In most things we do, we use the internet – from ordering a burger online, to sharing a moment with a friend, and sending an image over instant messaging.
However, the growth of technology has also brought about the growth of something a bit more sinister – cyber threats. Due to the pandemic, and the rise in remote work over the past two years, there has been a significant increase in several types of cyber-attacks.
So, how do you identify and mitigate these attacks? There are a variety of ways, but we’ll be talking about once specific way in this article – CSP.
What is CSP?
CSP stands for Content Security Policy. It is a response header that assists in the identification and mitigation of several types of attacks, including:
- Clickjacking
- Cross Site Scripting (XSS)
- Data injection attacks
A Content Security Policy is a defensive measure against attacks that rely on executing malicious content in a trusted web context via a security standard that provides an additional layer of protection.
With a CSP, you can limit which data sources are allowed by web applications; this is done by adding the appropriate CSP directive in the HTTP response header.
What vulnerabilities can a CSP prevent?
A Content Security Policy can prevent the following vulnerabilities:
- Dynamic JavaScript code using eval()
- Unsigned inline JavaScript in <script> tags
- Unsigned inline CSS statements in <style> tags
- Dynamic CSS using CSSStyleSheet.insertRule()
How to use Content Security Policy and Directives
Implementing CSP involves adding the Content-Security-Policy HTTP header to every response from the server; this will provide the webpage with values to manage the resources that the user agent is allowed to use.
Below are the properties that you can in the CSP header:
- default-src – an optional method if no other attributes are defined. This serves as a fallback for other CSP fetch directives. For directives that aren’t present like the media-src and script-src, the user-agent looks for the default-src directive’s content and uses it.
- script-src – locations from which external scripts can be loaded.
- img-src –locations from which images can be retrieved.
- media-src – locations from which rich media like videos can be retrieved.
- object-src – locations from which plugins can be retrieved.
- manifest-src – locations from which applications manifests can be retrieved.
- frame-ancestors – locations from which another web page can be loaded using a frame, iframe, embed, or applet element.
- form-action – URLs that can be used as part of an action in a <form> tag, meaning the browser restricts where the form can result from.
- plugin-types – the set of plugins that can be invoked via objects, embeds, or applets, defined using MIME types.
- base-uri – allows URLs in the src attribute of any tag.