Content Security Policy. One hash, or unsafe-inline

A strict Content Security Policy breaks the editor in a way that reads as a CSS bug rather than a policy block. The editor renders, the toolbar is there, the buttons work, and none of it has any styling at all.

The cause is a single directive. The editor injects its own stylesheet as a style element, and a policy that does not account for it refuses that element. Nothing is broken, and nothing loads the stylesheet either.

What it looks like when a policy blocks it

The toolbar loses its background, the buttons lose their states, and the frame loses its border. You get working buttons in a row with no visual grouping, which is exactly what a missing stylesheet looks like, so the instinct is to check the CSS rather than the headers.

The console names it if you look. A refused inline style is reported as a policy violation, and that message is the difference between ten minutes and an afternoon.

Add the hash to your Content Security Policy

This is the tighter of the two fixes and the only relaxation needed. The stylesheet is a fixed string, so it has exactly one hash.

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  style-src 'self' 'sha256-orTVCowD4pMvRhB1nyRLk7JNj6cB7ytzJp5JppCur/E=';

That hash is tied to the current stylesheet. It is not a general allowance, which is why it is the better option if your policy is otherwise tight.

Or allow inline styles instead

The simpler fix, and the one that never needs revisiting after an upgrade.

style-src 'self' 'unsafe-inline';

It is a wider allowance than a hash and it covers every inline style on the page rather than this one, so it is the right answer only if you have already decided that trade is acceptable.

What each policy actually does

Measured against a live policy rather than reasoned about.

What the editor does not need

No relaxation of script-src, which is usually the directive people expect to relax first.

The editor does not use eval, new Function or string timers, and it injects no scripts. It makes no network requests at runtime and loads no fonts or images of its own, so it needs no connect-src and no img-src. A policy of default-src 'self' is otherwise sufficient.

That is worth stating plainly, because an editor that demands unsafe-eval changes the whole calculation about whether to adopt it. The source is public if you would rather check that than take it on trust.

What changes when you upgrade

If you chose the hash, it is tied to the stylesheet and the stylesheet changes when the editor's styles change. A version bump can therefore invalidate the hash, and the failure is silent in the sense that matters. The editor keeps working and quietly loses its styling again.

The editor's styles have not changed between minor versions so far, so this is rare rather than routine. It is still worth a smoke test after an upgrade rather than assuming the hash survives, because the symptom looks like a CSS regression rather than an upgrade problem.

If you would rather never think about it again, take the unsafe-inline route and accept the wider allowance. If your policy is the reason you are reading this, take the hash and add the smoke test. A policy block and a theme that failed to apply look similar and are not, so the theming options are worth knowing before you spend an afternoon on the wrong one.