Content Security Policy (CSP) restrictions

Security guidelines and coding restrictions enforced by the Content Security Policy (CSP) when developing custom code in HTML Canvas widgets and Ubidots Pages.

Content Security Policy (CSP) restrictions

Ubidots enforces a Content Security Policy (CSP) on application domains to protect end users against cross-site scripting (XSS) and code-injection attacks. This policy applies to all custom code running inside an application, which includes both HTML Canvas widgets and Ubidots Pages.

Because of this policy, some coding patterns that browsers would normally allow are blocked at the application level. Code that doesn't follow the guidelines below may silently fail to execute, even if it works in a local environment or in the widget's preview.

Note: The policy is enforced per application domain. A widget or page may behave differently on industrial.ubidots.com than on your white-label application domain (e.g., app.yourcompany.com). Always test your custom code on the same domain your end users access.

1. Inline JavaScript is not executed

The CSP does not allow inline scripts. This means the following patterns will be blocked:

• Inline event handler attributes in HTML, such as onclick, onchange, onsubmit, onload, etc.

• <script> blocks written directly inside the HTML tab (or inside a Page's HTML).

• javascript: URLs in links or buttons.

All JavaScript must live in the JavaScript tab of the HTML Canvas (or the JavaScript section of a Page), and event handlers must be attached programmatically using addEventListener.

❌ Blocked — inline handler in the HTML tab:

<button id="export-btn" onclick="exportData()">Export</button>

✅ Allowed — element in the HTML tab, logic in the JavaScript tab:

<!-- HTML tab -->
<button id="export-btn">Export</button>

// JavaScript tab
document.getElementById('export-btn').addEventListener('click', exportData);

function exportData() {
  // Same logic as before — no functional changes required
}

Migrating from inline handlers to event listeners requires no changes to your business logic: the same functions are invoked, only the way they are bound to the DOM changes.

2. Avoid dynamic code evaluation

Avoid APIs that compile code from strings, as they may be blocked by the policy:

• eval()

• new Function('...')

• setTimeout('...' /* string */) and setInterval('...' /* string */) — always pass a function reference instead of a string.

3. Loading external scripts and libraries

• Load third-party libraries through the widget's Third-party libraries setting (see Third-party packages) rather than injecting <script> tags from the HTML tab.

• External scripts must be served over HTTPS. Scripts loaded over HTTP will be blocked.

• Some external script sources may be restricted on hardened application domains. If a library or external API (for example, a maps or charting provider) fails to load for end users, check the browser console for CSP errors and contact Ubidots support so the required origin can be reviewed.

4. Styles

Inline styles (the style attribute and <style> blocks) are currently permitted. However, we recommend keeping all styling in the CSS tab for maintainability and to future-proof your widgets against further policy hardening.

Troubleshooting CSP issues

If a button stops responding, a modal opens empty, or part of your widget/page does not render, open the browser's developer console (F12 → Console). CSP violations are reported with messages such as:

Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src 'self' ..."

or

Refused to load the script 'https://example.com/lib.js' because it
violates the following Content Security Policy directive: ...

Common fixes:

Symptom	Likely cause	Fix
A button or control does nothing when clicked	Inline onclick/onchange handler	Move the logic to the JavaScript tab and bind it with addEventListener
A <script> block in the HTML tab never runs	Inline script blocked	Move the code to the JavaScript tab
An external library or map fails to load for end users but works for owners	Script origin blocked on the app domain	Verify the HTTPS source, load it via Third-party libraries, and contact support if it is still blocked
Code works in preview but not in the published app	Different CSP between domains	Test on the end-user application domain