Skip to contentSkip to main navigation Skip to footer

What is Content Security Policy (CSP)?

Content Security Policy (CSP) is a security feature that helps protect websites from various attacks, such as Cross-Site Scripting (XSS) and data injection attacks. Here’s an easy-to-understand explanation of CSP and how it can be used to protect a website.

CSP is like a set of rules that you set for your website. These rules tell the web browser what kind of content (such as scripts, stylesheets, or images) it is allowed to load and where this content can come from. By setting these rules, you can prevent malicious content from being loaded on your website.


How Does CSP Work?

Websites can be vulnerable to attacks where attackers try to inject malicious code into the site. For example, an attacker might try to add a harmful script to your site that steals user data. CSP helps prevent this by restricting where scripts and other resources can come from.

  1. Define Policies: You define a policy (set of rules) in your website’s HTTP headers. These rules specify where resources like scripts, images, and styles can be loaded.
  2. Enforce Policies: When a user visits your website, the browser checks and enforces the CSP rules. If any content violates the rules, it won’t be loaded.

Example of a CSP Rule

Example 1: Default CSP

By default, Hide My WP Ghost sets a basic Content Security Policy to block plugins and Flash objects, enhancing security:

object-src 'none';
  • object-src 'none': This directive blocks all plugins and Flash objects, preventing potential vulnerabilities from these types of content.

Example 2: Allow Scripts from Your Own Website and a Trusted Site

Let’s say you want to allow scripts to be loaded only from your own website and a trusted third-party site. You would set a rule like this:

script-src 'self' https://trustedsite.com
  • script-src: This directive specifies where scripts can be loaded from.
  • 'self': This means scripts can be loaded from the same origin (your own website).
  • https://trustedsite.com: This means scripts can also be loaded from this trusted third-party site.

Example 3: Allowing Only Specific Sources for Different Types of Content

Imagine you have a website that loads scripts from a CDN, styles from your own domain, images from an image hosting service, and fonts from Google Fonts. Your CSP policy would look like this:

default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self'; img-src https://images.example.com; font-src https://fonts.googleapis.com; connect-src 'self'; frame-src 'self'; object-src 'none';
  • default-src 'self': By default, only allow resources from your own website.
  • script-src 'self' https://cdn.example.com: Allow scripts from your own website and a CDN.
  • style-src 'self': Allow styles from your own website only.
  • img-src https://images.example.com: Allow images from an image hosting service.
  • font-src https://fonts.googleapis.com: Allow fonts from Google Fonts.
  • connect-src 'self': Allow AJAX and WebSocket connections to your own website.
  • frame-src 'self': Only allow iframes from your own website.
  • object-src 'none': Block all plugins and Flash objects.

Example 4: Allowing Inline Styles and Scripts

In some cases, you might need to allow inline styles and scripts. Although this is less secure, you can still use CSP to limit where other resources can come from:

default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-src 'none'; object-src 'none';
  • default-src 'self': By default, only allow resources from your own website.
  • script-src 'self' 'unsafe-inline': Allow scripts from your own website and inline scripts.
  • style-src 'self' 'unsafe-inline': Allow styles from your own website and inline styles.
  • img-src 'self' data:: Allow images from your own website and data URIs (inline images).
  • font-src 'self': Allow fonts from your own website.
  • connect-src 'self': Allow AJAX and WebSocket connections to your own website.
  • frame-src 'none': Block all iframes.
  • object-src 'none': Block all plugins and Flash objects.

Example 5: CSP for WordPress Admin Area

To ensure security while allowing necessary functionality in the WordPress admin area, you can use the following CSP:

default-src https: 'unsafe-inline' 'self' data:; base-uri 'self'; frame-ancestors 'none'; object-src 'none';
  • default-src https: 'unsafe-inline' 'self' data:: Allow resources from secure origins, inline resources, the same origin, and data URIs.
  • base-uri 'self': Restrict the base URL for relative URLs to the same origin.
  • frame-ancestors 'none': Prevent the page from being framed by any other site.
  • object-src 'none': Block all plugins and Flash objects.

Setting CSP in WordPress Using Hide My WP Ghost

To set up CSP in WordPress using the Hide My WP Ghost plugin, follow these steps:

      1. Go to Hide My WP > Firewall > Header & Security.
      2. Look for the Content Security Policy (CSP) settings.
      3. In the CSP input field, enter your CSP rules. For example:
          default-src https: ‘unsafe-inline’ ‘self’ data:; base-uri ‘self’; frame-ancestors ‘none’; object-src ‘none’;
          1. Save settings and check the frontend

            By setting up CSP in your WordPress site using the Hide My WP Ghost plugin, you can effectively control where resources can be loaded from, enhancing your website’s security.


            Benefits of Using CSP

            • Reduces XSS Attacks: By limiting the sources of executable scripts, CSP significantly reduces the risk of XSS attacks.
            • Mitigates Data Injection Attacks: CSP helps prevent attackers from injecting malicious content into your site.
            • Improves Website Security: Overall, CSP strengthens your website’s security by controlling where resources can be loaded from.

            Conclusion

            CSP is a powerful security feature that can help protect your website from various types of attacks by specifying where content can come from. By defining a set of rules and enforcing them through HTTP headers, you can ensure that only trusted sources are allowed to load content on your site, thus keeping it safe from malicious activities.