Nounce

Details
Written by: cayenneAdmin
Category: Plug Ins
Hits: 21

1. Quick recap of what we had (so you don’t have to re-ask everything)

a) RSForm and where to put CSS

  • RSForm does not require its own CSS folder; it happily uses template CSS.

  • The usual place is still something like:
    /media/templates/site/your_template/css/user.css (or your child template’s custom CSS file).

  • If user.css isn’t being picked up, it’s usually either:

    • Not registered/loaded in the template’s index.php / asset manager, or

    • Overridden by RSForm inline or component CSS with higher specificity.

  • You don’t need a special RSForm folder just for CSS unless you want one for organization; Joomla doesn’t demand it.

b) System – HTTP Headers plugin & {nonce}

The plugin lets you send security headers like:

  • Content-Security-Policy (CSP)

  • X-Frame-Options

  • Referrer-Policy

  • HSTS

  • Cross-Origin-Opener-Policy, etc.

The {nonce} placeholder is used when CSP is set to something like:

Content-Security-Policy: script-src 'self' 'nonce-<random>' ...

The plugin will dynamically generate a nonce value per request and replace {nonce} when you use:

  • Those are usually covered by style-src 'self' (or whatever domains you allow) in CSP.

  • Inline attributes like:  <h1 style="background-color:grey">

  • are considered inline styles and are blocked by a strict CSP unless you loosen CSP using 'unsafe-inline' or hashes. They don’t use a nonce. So:

    • They keep working only if your CSP is not strict about styles, or

    • You explicitly allow inline styles with 'unsafe-inline' (less secure).

c) Is this new to Joomla 5.4? Where are the settings?

  • The System – HTTP Headers plugin is part of Joomla 4+ and 5+, not exactly brand-new to 5.4, but it’s being pushed more as security hardening.

  • You manage it at:
    System → Plugins → “System – HTTP Headers”
    From there you can:

    • Enable/disable HSTS, CSP, Referrer-Policy, etc.

    • Add CSP rules.

    • Use {nonce} in your own manually added <style> / <script> tags.

You mentioned:

  • HSTS: disabled

  • CSP: disabled

  • X-Frame-Options: enabled

  • Referrer-Policy: strict-origin-when-cross-origin

  • Cross-Origin-Opener-Policy: same-origin

  • Force HTTP headers: no value

That’s a perfectly reasonable “conservative but safe” baseline while you’re still building/debugging.

2. So… when should you start turning CSP on?

Short version:
Turn CSP on once your site is structurally stable, and you’re ready to spend a bit of time watching what it breaks.

More concretely, I’d use this rule of thumb:

Step 1 – You have a fairly stable stack

  • You already know which components/plugins you are using (RSForm, EasyBlog, etc.).

  • You’re not constantly adding random new scripts from new CDNs every day.

  • Your template and main JS/CSS assets live mostly on:

    • Your own domain (self), and/or

    • A small, known set of CDNs (e.g., Google Fonts, jsDelivr, etc.).

That makes CSP much easier to configure.

Step 2 – Start with “Report-Only” mode (ideal moment for you)

You should consider enabling CSP as soon as:

  • The public-facing site is reachable (even if soft-launched), and

  • You have time over a few days to look at logs / browser console.

Then:

  1. Set CSP in Report-Only mode first (if you’re doing raw headers in Apache/NGINX) or use a very permissive CSP in the plugin.

  2. Browse your site, submit RSForms, test admin, etc.

  3. Look at:

    • Browser DevTools → Console → CSP warnings.

    • Any CSP reports (if you configure report-uri or report-to).

This period is where you gather the “ugly list” of what needs to be allowed (script-src, style-src, img-src, etc.).

Step 3 – Lock it down gradually

You should move from “off” to “on” when:

  • You’ve identified all legit script/style sources.

  • You’re confident:

    • RSForm works (validation, AJAX, etc.).

    • Any external tracking scripts you actually want (analytics, chat widgets) are included in script-src.

    • No critical admin workflows are being blocked.

Then:

Step 4 – Specific to your situation

For you personally, I’d say:

  • Start considering CSP now, but:

    • Keep it off or very loose on any domain where you’re still doing heavy development or experimenting with new JS-heavy components.

    • Begin serious CSP on more “finished” public sites where:

      • You’re not constantly adding random scripts,

      • Security / reputation matters more (e.g., anything handling user data, forms, logins).

Given your stack (Joomla 5, RSForm, plus security plugins like Admin Tools/Akeeba in other sites), CSP is worth the effort—just staged.

3. If you want, we can rebuild a “starter CSP” together

If you’d like to go one step further without re-typing everything we lost, we can:

  1. Pick one domain (e.g., CayenneDesign or another),

  2. You tell me:

    • What external services it uses (CDNs, Google Fonts, analytics, chat, etc.),

  3. I’ll propose:

    • A concrete CSP header you can paste into the HTTP Headers plugin,

    • With notes on where to use {nonce} and which inline bits need refactoring.

If you phrase the next question like:

“For site X, here are the external scripts/styles/images I use: … Please propose a CSP config for the Joomla HTTP Headers plugin.”

…I can give you something very close to copy-pasteable.

New Articles