Paths with generated slugs to not fulfil the selection process -- for example: "2022/02/01/foo.html". Find a way to apply the CSP to related paths (e.g. archives, tags etc).

Do a recursive search up until _config, or package.json.

Allow users to see which path matches to which pattern.

This means:

^path$:
  prod:
    directives: ...
  dev:
    directives: ...

Instead of:

yml
prod:
  ^path$:
    directives: ...
dev:
  ^path$:
    directives: ...

This avoids duplication of patterns. It still allows the user to apply patterns to one environment but not the other.

This is for CI etc.

Is there a way to make sense of the document without running it in a browser? Can violations be detected at build time?

• exclude mode from prod base policies, since this has no meaning;
• logger: validate host against URL; possibly the path too;

Allow for merg/replace of directives, optionally set by the user.

Allow the user to specify custom env variables for each env:

env:
  - prod
  - production
  - ""

Apply beautification only during testing. The snapshots are hard to read.

Test that it logs to console.

This will require an HTTP client, and a sandbox for the Hexo dist/public files.

Defaults to use:

• mode: "merge" => combineEnvs() expects this to be set;

Joi returns an object like so: { value, error }. value will always contain something, for example if you misspell a key, it will include both correct and incorrect spellings, but defaulting the correct.

Do something like:

const validated = Joi.validate(foo);
if (!validated.error) {
  doSomething(validated.value)
}

Validate everywhere that savePolicy is used. Typically in the primary index file, or applyCSP.

Should this be done? It seems like not halting the build on a security violation would be bad for CI.

Find a way to do this properly.

Issues:

1. the after_render filter fires for each path, throwing within that means throwing hundreds of errors;
2. throwing within the root index means throwing for the CLI too, since it also loads plugins -- it makes no sense to do this;
3. the hexo testing utils hates exceptions, and causes unhandled rejection error;

In short: can't throw on load, during rendering, or during testing.

This needs investigation. Hexo provides env awareness -- I think "development" means generate, server commands; "production" means deploy.

This is untested, and results in production policies being applied 100% of the time. Ignoring dev logger and dev policies.

You may be able to remove this feature (and tests) if #38 is implemented.

This means you will also have to test the scenario where two expressions match a single document -- ensure that they merge/replace correctly.

Support the same format as the URI syntax:

csp
  mode: replace
  default-src: 'self'
  img-src: 'self'

Suppose merge mode by default.

Right now the default directive does nothing, apply it to paths that don't match -- i.e. return it as a default for Config.directives(path).

Make this store policy objects internally, and contain all policy behaviours.

Create a server that will log violations to stdout/stderr.

So that users can lift prod policies out of it and use them to serve a production logger.

It's cloned, and it seems wasteful and unnecessary.

First ensure that style tags etc are in their final form (minified), then compute their hashes.

Right now, all policies need rebuilding for every after_render:html due to them being Policy instances. Implement a way that is more efficient. You will only need to refactor Config.#buildPolicies(); mergePolicies().

You WILL need to validate (#2) the config separately; set defaults separately. Perhaps use a pipeline.

Use a runtime schema validator for the config object.

Besides typical validation, ensure that the directive keys are valid. Instead of throwing, just warn. This means modern directives wont immediately cause issues.

This relates to #6.

The default is merge -- always.

Front-matter takes precedence, then URI specific directives, then the default directives.

First, merge/replace the production environment, then merge/replace with development environment. These respect the env mode and individual frontmatter/URI modes.

csp:
  mode:
    env: merge
  prod:
    directives:
      foo/index.html
      mode: replace

This is frontmatter, it replaces the layer below it.

---
csp:
  mode: replace
---

Examples:

If front-matter specifies replace, then that is the final form. If that's then merged with development environment, then it's a mix of the two.

If front-matter is merge and URI is replace, then the final form is front matter + URI (replacing default).

Instead of including them via meta tag. report-uri does not work in meta tags.

Related commit: 52502ab

This may not be necessary if #38 is implemented.

For example, frontmatter dev policies require that prod policies are specified. This shouldn't be necessary.

This means targeting elements with an href, src, and number of other attributes.

This will be a big task.