Add Content Security Policy to WordPress [2/4]

The first part explained the basics of a content security policy (CSP) and suggested a roadmap for implementation. This part prepares a WordPress site for the implementation.

First, create a child theme of your current theme. A basic child theme is composed of a directory and two almost empty files: style.css and functions.css. Any further modifications will happen in this directory. Essentially, the child theme contains modifications to the original theme and allows automatic updates to the original theme as required. It also allows us to simply switch back to the original if something goes wrong during the development process.

With the child theme in place, consider adding security headers to the site. This is an optional, but beneficial step. Make sure you are comfortable with FTP and editing the .htaccess file; if not, simply skip this step and leave it for some other time. Continue reading “Add Content Security Policy to WordPress [2/4]”

Add Content Security Policy to WordPress [1/4]

Policy: a principle of behavior, wise conduct, a tool of governance, overall intention and direction as formally expressed by management.

By adding a Content Security Policy (CSP) to a blog, we can specify resources a reader’s browser (Chrome, Firefox, Edge) is allowed to use on a site. We can specify from where a browser can load scripts, styles, images, media, and objects. Specify to where a form can post data. Enable or disable inline scripts and styles; even exactly specify the fingerprint of allowed scripts and styles. Require that each file must have a specified fingerprint to make sure it was not modified.

You may have heard of a recent British Airways hack, or how thousands of UK and Australian governments’ sites were hijacked to mine crypto-currency. Both were compromised via a modified script file. Also a fresh news story about scripts injected into shopping carts. Attacking WordPress sites en masse is nothing new, and in most cases malicious scripts are injected into sites through some weakness, completely out of site owners’ control. Something should be done. Fortunately some smart people figured out how to remedy the situation, at least reduce the risk, so all we have to do is implement few recommendations.

To see how a CSP on a WordPress site looks, check out the source of this site. Right-click anywhere on the page and select “View Page Source” or type Ctrl+U. Take a look at the first <meta> tag, just below the <head>.

What does this do? The policy:

  • disables defaults for directives requiring sources (-src),
  • specifies two sha256- integrity attributes of inline scripts allowed to run,
  • allows loading of scripts from this domain and Cloudflare cdn,
  • specifies one sha256- integrity attribute of an allowed inline style,
  • allows loading of styles only from this domain,
  • allows loading of images only from this domain,
  • prevents loading of fonts,
  • prevents loading of objects,
  • allows forms to post only to this domain,
  • requires integrity attributes (sri) to be specified for styles and scripts.

Mozilla has a good reference of policy directives. This is likely to change as new specifications are introduced, but it is a good start. Once the policy is in place it is easy to tinker with.
Continue reading “Add Content Security Policy to WordPress [1/4]”

WordPress tags

One can find quite a few tag-related plug-ins for the WordPress, but adding tags to your old posts may prove to be quite a tedious task. Here is a simple method of adding tags to old posts, but this one is not for faint hearts—you have to run a SQL statement against the database.

Before you start

Back-up the database, better safe than sorry.


The following technique works only if the table wp_term_taxonomy has not been modified by a weird plug-in or manually; columns term_taxonomy_id and term_id should contain same numbers. To verify this, run the following:

SELECT COUNT(`term_taxonomy_id`)
    FROM `wp_term_taxonomy` 
WHERE `term_taxonomy_id` != `term_id`;

The result should be 0. If the returned result is greater than 0, do not use this procedure.

Step 1

In the Manage–>Tags list, note IDs of your tags. Float the mouse pointer above the tag name to see the  “ID” displayed in the status bar of your browser. For example, some of my tags:

ID Tag name
12 data collection
13 six sigma
14 standard deviation
18 database

Step 2

Note IDs of your posts; floating the mouse pointer above a post name displays the “ID” in the status bar of the browser.

Step 3

Create a table of associations between post and tag IDs.

Suppose we want to add tags “database” (id=18) and “data collection” (id=12) to the post Basic database checkup (id=95); tags “six sigma” (id=13) and “standard deviation” (id=14) to the post Mathematician with no diploma (id=45).
The table would look like this:

Post ID Tag ID
95 18
95 12
45 13
45 14

Step 4

Based on the previous table, add rows to the wp_term_relationships using the code snippet. If you have more rows just follow the pattern below the “VALUES” keyword. The third number within parentheses is always 0.

INSERT INTO `wp_term_relationships` 
    (`object_id`, `term_taxonomy_id`, `term_order`)
    (95, 18, 0),
    (95, 12, 0),
    (45, 13, 0),
    (45, 14, 0);

Worked nice for me on WordPress 2.5.1.