IBBoard Secure and problems after installing

Hi,
I am new in LiteCart and I have installed a few addons, the latest is IBBoard Secure. After installing it I have only problems. Somehow I can add new product but:

• I can't select image
• I can't select category
• whatever number I put in stock it can't be saved
• it does not recalculate prices
  and so on...

I browsed to the folder Logs, opened Error.log and there are tons of messages like:

[20-Sep-2025 23:55:54 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 1; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-elem; line-number => 545; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => .operation {  background: #f8f8f8;  pâ¦; source-file => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; status-code => 200; violated-directive => style-src-elem
[20-Sep-2025 23:55:54 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 9; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => script-src-elem; line-number => 27343; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => // Tabs  let new_tab_index = 1;  whiâ¦; source-file => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; status-code => 200; violated-directive => script-src-elem
[20-Sep-2025 23:55:54 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 27; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-elem; line-number => 857; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => :is([id*='google_ads_iframe'],[id*='taboâ¦; source-file => <anonymous code>; status-code => 200; violated-directive => style-src-elem
[20-Sep-2025 23:55:54 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 17; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-attr; line-number => 903; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => padding-top: 4px !important;; source-file => moz-extension; status-code => 200; violated-directive => style-src-attr
[20-Sep-2025 23:55:54 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 17; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-attr; line-number => 903; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => padding-top: 4px !important;; source-file => moz-extension; status-code => 200; violated-directive => style-src-attr
[20-Sep-2025 23:55:54 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 19; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-elem; line-number => 295; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => #s3downbar-ibmbeeacmbeeaebmfjpmnlgkhoejiâ¦; source-file => moz-extension; status-code => 200; violated-directive => style-src-elem
[20-Sep-2025 23:55:54 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 19; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-elem; line-number => 295; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => #s3downbar-ibmbeeacmbeeaebmfjpmnlgkhoejiâ¦; source-file => moz-extension; status-code => 200; violated-directive => style-src-elem
[20-Sep-2025 23:57:18 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 27; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-elem; line-number => 857; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => :is([id*='google_ads_iframe'],[id*='taboâ¦; source-file => <anonymous code>; status-code => 200; violated-directive => style-src-elem
[20-Sep-2025 23:57:18 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 17; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-attr; line-number => 903; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => padding-top: 4px !important;; source-file => moz-extension; status-code => 200; violated-directive => style-src-attr
[20-Sep-2025 23:57:18 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 17; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-attr; line-number => 903; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => padding-top: 4px !important;; source-file => moz-extension; status-code => 200; violated-directive => style-src-attr
[20-Sep-2025 23:57:18 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 19; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-elem; line-number => 295; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => #s3downbar-ibmbeeacmbeeaebmfjpmnlgkhoejiâ¦; source-file => moz-extension; status-code => 200; violated-directive => style-src-elem
[20-Sep-2025 23:57:18 Europe/Ljubljana] CSP Report: blocked-uri => inline; column-number => 19; disposition => report; document-uri => <mywebshopurl>/Admin/?app=vmods&doc=edit_vmod&vmod_id=ibboard_secure; effective-directive => style-src-elem; line-number => 295; referrer => <mywebshopurl>/Admin/?app=vmods&doc=vmods; script-sample => #s3downbar-ibmbeeacmbeeaebmfjpmnlgkhoejiâ¦; source-file => moz-extension; status-code => 200; violated-directive => style-src-elem

The fun part is that I can't even disable the mod...
I set my page to use PHP 8.4 if it helps. What can I do?

Best regards,
Goran

I am moving this topic to the addon forum.
LiteCart 3.0 is coming with some CSP enhancements.

Hi, no problem moving theme to new subforum. I don't know when You plan to release LiteCart 3.0 but at the moment I need make things working again.

See if you can replace the folder with the original files. I haven't played around with this addon myself.

@ibboard do you have clues what the cause of the problem is?

Those log messages are because the CSP is doing its job. But there shouldn't be any errors raised from the admin control panel.

Most of those error log lines are effectively noise - they're style attributes and elements not loading, so it might not look right but everything would still function.

The important line is the script-src-elem entry. Looking at the code on my server and the cache, I can see that the script with let new_tab_index = 1 is a <script> tag in admin/vmods.app/edit_vmod.inc.php. But my cache shows that being rewritten as <script<?php echo document::$nonce_attribute; ?>> (as expected), so it would get a nonce and be allowed by the policy.

One of the mod instructions (line 85) does that replacement in admin/vmods.app/edit_vmod.inc.php and should warn if it fails. Which suggests that something else is interfering with the replacement and you should be getting a warning. Are you getting a warning? And do you have any other vmods installed that modify admin/vmods.app/edit_vmod.inc.php?

If you want to disable the mod and the UI isn't working then either delete the vmod file or rename it from .xml to .disabled.

Hi, first of all thank You for the explanation. I would like to continue using the modification but until the new update is available, I will probably disable it. I can't do it in the admin panel (button save does not work, as well as in the list of mods "with selected" which is grayed and the buttons as well). As I said, the log I posted is only few lines, there is much much more than this. If interested, I can send the whole log somehow.

Regarding the interference with some other mods, I have these: Google translate, Countryflags, IBBoard Secure and disabled Google analytics, IBBoard V.09. And the IBBoard Secure V1.0 was installed the last.

Best regards,
Goran

The log won't tell me much that we don't already know.

The "IBBoard Secure" mod is supposed to edit the style tags and other elements to add a nonce value that matches the CSP header. Those two things in combination tell the browser that it can trust the styles and scripts. And if it can't then it reports it to the endpoint (which logs it) because it should mean that someone compromised your site and added potentially malicious code.

But in this case it appears to mean that either a) the mod didn't make the changes (and should be showing an error on the page to say that an edit wasn't applied) or b) the mod made the changes but somehow the nonce value in the header doesn't match the one that it embedded in the HTML.

The next steps for debugging are:

1. Open the Developer Tools in the browser of your choice (e.g. press F12 in Firefox)
2. Click on the "Network" tab
3. Open the LiteCart admin control panel
4. In the Developer Tools, select page and look at the headers. Find the Content-Security-Policy response header and note down the part of the nonce-... value after the hyphen (to be secure, it changes with each request)
5. Still in the Developer Tools, click the "Response" tab and look at the HTML. You're looking for nonce="..." attributes. Record the value
6. Taking those two values:
   • If they match then some of the changes are applying and you need to work out which of your other plugins is interfering with the changes from IBBoard Secure (and why it isn't erroring on them)
   • If there aren't any nonce values in the HTML then the plugin isn't being run at all and there should be lots of warnings (or something is conflicting by overwriting its changes)
   • If there are nonce values and they don't match then you need to identify which part of your server config is either a) replacing the initial CSP_NONCE value in PHP's $_SERVER variable after LiteCart starts using it (if you are running Apache with mod_csp or other modules that set that value) or b) overwriting the content-security-policy header and not setting the CSP_NONCE value in $_SERVER (which would make the vmod generate a random nonce that then gets ignored)

Hi, thank You for the instructions above. Unfortunately I didn't have time until today to check the above written.
To answer You, the nonce- codes matches so I disabled all the mods I installed: Fraud. Google translate, Country flags, Google analytics, invoice as a payment and until I disabled the ibboard_secure.XML in "vmod" I could not update the quantity of the product, the "Default category" combo box in edit product has returned to normal and so on. Unfortunately I can't enable IBBoard secure (brute force) but okay.

The question is, is there a language problem here as well? My default language is Slovenian (although not properly recognized in Firefox for example) which has decimal point and comma as delimiter for thousands.

The language shouldn't make a difference. The CSP header and attribute are there to get the scripts and styles approved. The content is irrelevant. The fact that the script tag has an attribute that matches the header is enough to say "it is okay to run the contents of this script".

You provided the errors that are in the server logs, which gives some details. But your browser should also print errors before it sends the CSP error reports. What do you see in the "Console" part of the developer tools when you have the vmod enabled and view a page that doesn't work? (There will be some false-positives because of browser scripts and thing that happen in debug mode, but it might show something that explains the problem a bit more)

Also, can you paste the contents of the content-security-policy and content-security-policy-report-only headers? Maybe the header hasn't been generated correctly on your server. There shouldn't be anything private in there (the nonce is a one-time code and everything else will be sent to anyone who visits your site!)

"IBBoard Secure (Brute Force) shouldn't be necessary for most people and is just there if you use a custom theme and don't want to fix it, or your other plugins add extra pages and you don't want to make the required changes yourself.

I'm still at a loss as to how this is broken without seeing lots of errors on the page (either from the VMod failing to apply when the changes should all be tagged with onerror="error" or from it generating invalid content if something else was interfering or didn't match the expected code). Are you using the default admin theme, or have you got a custom admin theme?

I hope I can present You all here:

content-security-policy
  frame-ancestors 'self'; base-uri 'self'; report-to csp-endpoint; report-uri https://*****.domain.si/csp-report;
content-security-policy-report-only
  default-src 'none'; img-src 'self'; media-src 'self'; font-src 'self'; script-src 'report-sample' 'self' 'nonce-Q1qD3SjOg01izKKUeMu5My5X' 'strict-dynamic'; style-src 'report-sample' 'nonce-Q1qD3SjOg01izKKUeMu5My5X'; frame-src 'self'; connect-src 'self'; form-action 'self'; report-to csp-endpoint; report-uri https://*****.domain.si/csp-report;

But your browser should also print errors before it sends the CSP error reports. *

Correct, there are 10 errors 503 there and let's say, the first one is, the others are vitually the same (the webshop is in maintenance mode):

content-security-policy
  frame-ancestors 'self'; base-uri 'self'; report-to csp-endpoint; report-uri https://*****.domain.si/csp-report;
content-security-policy-report-only
  default-src 'none'; img-src 'self'; media-src 'self'; font-src 'self'; script-src 'report-sample' 'self' 'nonce-X6VK3fTIoJGEgYDeUgxqMu/w' 'strict-dynamic'; style-src 'report-sample' 'nonce-X6VK3fTIoJGEgYDeUgxqMu/w'; frame-src 'self'; connect-src 'self'; form-action 'self'; report-to csp-endpoint; report-uri https://*****.domain.si/csp-report;

I do not have any themes installed. I tried with classic but it didn't work. I think there are some PHP options I should turn on or maybe off...

Hope it helps?

One more thing... I switched to console and after some POST https://******.domain.si I see this:

Content-Security-Policy: (Report-Only policy) The page’s settings would block an inline style (style-src-elem) from being applied because it violates the following directive: “style-src 'report-sample' 'nonce-Q1qD3SjOg01izKKUeMu5My5X'”. Consider using a hash ('sha256-+OsIn6RhyCZCUkkvtHxFtP0kU3CGdGeLjDd9Fzqdl3o=', requires 'unsafe-hashes' for style attributes) or a nonce.

Based on those CSP headers, your site should be in "report only" mode, because the style-src and script-src are only defined in content-security-policy-report-only and not in content-security-policy. It should not be blocking any of the scripts or style sheets. The whole point of report-only is to report errors without blocking things while you're working out whether your lockdown is correct or not.

The 503 errors may be the root of the problem. Because I wouldn't expect you to be getting "service unavailable" errors. Which URLs are giving 503 errors? And is there a meaningful error reported in the page content if you click on them and look at the "response" section of the "Network" tab?

Also, do all of the CSP reports in the console say Content-Security-Policy: (Report-Only policy)? Do any of them just say Content-Security-Policy:?

The 503 errors may be the root of the problem. Because I wouldn't expect you to be getting "service unavailable" errors. Which URLs are giving 503 errors? And is there a meaningful error reported in the page content if you click on them and look at the "response" section of the "Network" tab?

URL is pointing to my shop store URL and looking at the details of the first 503 error:

content-security-policy
  frame-ancestors 'self'; base-uri 'self'; report-to csp-endpoint; report-uri https://*****.domain.si/csp-report;
content-security-policy-report-only
  default-src 'none'; img-src 'self'; media-src 'self'; font-src 'self'; script-src 'report-sample' 'self' 'nonce-tMJbc+H5o4J9ljhWq8f/+04/' 'strict-dynamic'; style-src 'report-sample' 'nonce-tMJbc+H5o4J9ljhWq8f/+04/'; frame-src 'self'; connect-src 'self'; form-action 'self'; report-to csp-endpoint; report-uri https://*****.domain.si/csp-report;

Originally there is no folder "csp-report", nor file with such name. But if I create folder csp-report then the errors 503 are gone and I get line that in the column "TRANSFER" says "NS_ERROR_UNEXPECTED". I guess it is related to access limitations of the folder.

Unfortunately the creation of the folder "csp-report" does not solve the problem with entering the stock, the default catalogue combo box and so on...

The /csp-report path should be provided by the pages/csp-report.inc.php file that's included with the VMod. That's why you're getting the log entries about CSP violations. Litecart will route any URL in the form /something-with-optional.ext to pages/something-with-optional.ext.inc.php.

NS_ERROR_UNEXPECTED is a nameserver error. It's DNS. I don't understand how the existence (or not) of a folder on your server would affect that. I have found that the Developer Console can occasionally show errors that you can think of as "false-positives". It's not that it's lying and telling you an error happened when it didn't. The error happened. But the error only happened because you've got the Developer Console open and something in the browser behaved differently.

Alternatively, some "DNS" errors are actually a plugin like uBlock Origin or a Firefox security setting blocking a connection.

As for the details of the 503 errors, I don't need to see the CSP headers to see if they relate to the problem. We've confirmed that those headers are correct. I need to see the URLs that are failing and any errors that are reported in the "Console" section of the Developer tools or in the content of the failed pages.

After some initial issues (and then some delays on my part), I've managed to get in to Goranbru's admin control panel. At least part of the problem appears to be that some of the <script> and <style> tags aren't being collected and moved to the end, because they don't have the nonce in them.

One example is the Chartist scripts from admin/graphs.widget/graphs.inc.php. When you load the main admin control panel, the JS console shows an error that Chartist doesn't exist, because the Chartist script was moved to the end of the page, but the script importing it wasn't moved.

So the breakage isn't because the vMod is causing things to be blocked. It's because some elements aren't being collected and so try to execute before the libraries that they depend on are loaded and available.

However, I'm slightly confused. Because there's a big "replace all of the <script> tags" block for {admin/{catalog.app/{csv,edit_attribute_group,edit_category,edit_manufacturer,edit_product,manufacturers},countries.app/{countries,edit_country},currencies.app/currencies,customers.app/{csv,customers,customer_picker,edit_customer,newsletter_recipients},geo_zones.app/{geo_zones,edit_geo_zone},graphs.widget/graphs,languages.app/languages,modules.app/modules,orders.app/{add_product,orders,product_picker},pages.app/edit_page,reports.app/{monthly_sales,most_shopping_customers,most_sold_products},settings.app/settings,slides.app/{edit_slide,slides},translations.app/translations,users.app/{edit_user,users},vmods.app/{vmods,edit_vmod}},includes/templates/{default.admin/{pages/login,views/notices},default.catalog/{pages/{checkout,create_account,edit_account,order,printable_packing_slip,printable_order_copy,regional_settings},views/{box_cookie_notice,box_filter,box_product,notices}}}}.inc.php that literally just finds <script> and replaces it with <script<?php echo document::$nonce_attribute; ?>>. And that file list (when expanded) includes admin/graphs.widget/graphs.inc.php. So the <script> tag in that file should be being replaced. But it's still showing as <script> and there's no error, despite it being set as onerror="warning".

I'm going to poke further when I have time, but @tim - is there any way that a vMod can fail to replace and not error or fail the health check?

Edit:

If I edit the "find" from <script> to <script > (extra space) then I get some errors that it can't find the pattern. But mostly from notices.inc.php. So it's definitely trying to do the edits. But maybe not all of them. And it isn't erroring when the other files aren't edited.

(There also appears to be a bug where it isn't handling a top edit correctly - it wants some find content, even though a top (or bottom) doesn't have anything to find. Unless I've manage to get it wrong in a way that still works for applying the vMod but not editing it in the UI.

Edit 2: Nevermind. The bug in the edit is the same as the other bugs. The input should get disabled by a script when it's a top, bottom or all, but that script is one of the ones that doesn't get moved, so it's failing, so the save tries to access it, finds that it's an empty search and raises a validation issue.

Think I found the root cause. And it's a vMod behaviour that I wasn't aware of.

Looking at the Health Check info then there aren't any relevant failures (there's one failure, but it's in the packing slip, which won't affect the rest of the admin control panel). But if you pay attention to the individual files under each brace-expansion group then the big {admin/{…app-paths},includes/{…other-paths…}} blocks only show edits for the includes and not the admin/ paths. Because @goranbru changed the admin path to a different path. Meanwhile, all of the other replacements that are for admin/… are showing up with the path renamed.

What I think is happening (but haven't had time to confirm) is that vMod is intelligently updating the admin/ path when the path starts with admin/. But when it's {admin/…,other-path…} then it's too complex and it doesn't replace it and so doesn't find the paths or error! This feels like a bug in vMod, @tim. But maybe I'm just doing unusual things in abusing the brace expansion with such big lists 😁

Just to confirm that I found the source of the problem in lib_vmod.inc.php (labelled as "backwards compatibility", although that might just mean the line after it):

self::$aliases['#^admin/#'] = BACKEND_ALIAS . '/';

That alias only works if admin/ is that the start of the path. But if your path definition is {admin/…,includes/…} then it won't match, so it won't replace, so it won't find the files and make the edits.

But I guess it's easier/more efficient to replace the pattern once and glob with that rather than trying to expand it and replace on each expanded path individually. And if it's not anchored to the start then it would be hard not to also match path/to/admin/… (because even if you do a look-back for "/" then it could be path/to/{admin,other,etc} (the only saving grace being that LiteCart doesn't generally use that pattern - but that doesn't mean that mods won't).

And there's no error handling for "you tried to glob a file that doesn't exist". Which… I guess could be tricky (and wouldn't work with "*"), but also means that there's a whole class of vMod errors that aren't raised.

I've published v1.1, which duplicates the edits to avoid the alternative path problem in vMod globs, fixes the packaging slip edits, and improves what is logged by the CSP Report page. Hopefully that should work for everyone, whether they've renamed the admin directory or not.