This page lists the scripts used by Cameo forms and documents changes to them. This helps you meet your regulatory obligations for pages on your website that embed forms which take payments.
See Cameo Scriptwatch and cameocsp WordPress plugin for how you might use this information.
You might want to bookmark this page. In particular, the Changes section.
About scripts on your website pages
A script (in this context) is a computer program written in the JavaScript language that is supplied by, and along with, a web page. It is executed by the browser on the visitor’s computer. A script can change the appearance and behaviour of the page. It can respond to the buttons the visitor presses. A script has some limitations on what it can do (for example, it can’t access files on the visitor’s computer without explicit permission). But it can change the page content, so it could replace a payment form, for example, with a malicious one that looks similar. If a website loads a script from a third-party, the website has to trust that script to do what it claims; and to be sure that it isn’t changed in unexpected ways in the future.
Your page should already be protected against:
- rogue scripts being introduced, using a content security policy (which says where the page is allowed to include scripts from), and
- changed scripts loaded from content delivery networks (such as Google Fonts or jQuery), using integrity attributes.
However, this doesn’t deal with:
- scripts loaded from trusted sites violating that trust by making malicious changes, or
- these scripts, or your own site, being hacked to inject additional or changed scripts.
This is relatively unlikely, but it is a serious problem when it does happen. (The risk is a great deal higher when the site carries advertising from third-parties, where you have less control over what its scripts do). The more likely causes are:
- JavaScript in a Cameo form has been updated to either fix a bug or add new functionality. If the script is coming from Cameo (via your forms domain), then check the change history below for whether this is an expected update. Cameo uses a slightly different URL for the script after each change (the version number changes), so these often show up as a removal and addition rather than a change. If a change is to the code common to all forms, each form would show the change separately.
- An automatic or manual update to a WordPress plugin or a core update, or whatever system you are using. You should check when this happens and verify it is an appropriate change.
There are three variations to how scripts are introduced into web pages:
- <script src=”…”></script> – those loaded by making a separate request to your server or a third party that you permit. These are characterised by a <script> element having src attributes (whose value is the URL of the script).
- <script>…code…</script> – so-called inline scripts where the JavaScript code is included directly between <script> and </script>.
These should be protected with a hash in your content security policy. A hash is a relatively short but string that is calculated from and uniquely identifies the script content. If one of these has changed, the hash will no longer be valid, so the script may not be loading. In that case, Cameo Scriptwatch would show the script as removed.
Once you have confirmed the validity of the script, you can get the new hash and permit the script from the browser developer tools, the cameocsp WordPress plugin, or the Scriptwatch notification message.
Note that if you have automatic updates turned on, an inline script that is required by the page for it to work would leave your site broken until you can permit an updated script. - <img … onerror=”javascript:…code…”> and similar – event handler attributes, where an HTML element includes an attribute which says to run JavaScript when something happens (an image failing to load, for example). You should never allow such scripts. You should not use any plugin which employs them. Your content security policy should not include ‘script-src ‘unsafe-inline’’ (which would allow them).
Cameo form scripts
Unless show otherwise, all Cameo’s form scripts load from your form domain, as shown in forms → server configuration.
| /form-name.js | Provides all the interaction common to all forms, including moving from step to step through the form. (In version 11, forthcoming, this will reduce to a simple stub specific to the form, with the bulk of the code loaded once only across all forms, and therefore can be cached by the browser, but at present similar code is loaded separately for each form). |
| /impl/form-type.js | Provides the interaction specific to the particular type of form. For example, this provides field-specific error checking for each step of a form before the data it collects is sent to the server. |
| /impl/cameopay.js | Provides code specific to each payment provider required by them to display the step which collects payment details, and then submit it to them. In some cases, this displays a form (often provided by the payment provider) to take details (such as their card number to make a card payment). In others, it redirects the customer to the provider’s website to take the details (such as their bank account number to set up a direct debit mandate). (In version 11, this is split into provider-specific scripts, and only the one required for the payment method requested is loaded). |
| https://code.jquery.com/jquery-3.2.1.min.js | Basic utilities for manipulating the HTML DOM (the web page, and in particular here, the form). Without this, a form cannot load. However, WordPress provides jQuery as well (possibly a different version), and when that happens, the form uses WordPress’ version (loaded locally from your website WordPress installation, not from code.jquery.com). If we do need to load it, it is SRI checked (that is, will not load unless the hash provided for it matches the code provided by the CDN). |
| /leaflet-0.7.7/leaflet.js | A utility to display and interact with a map, when the form requires the customer to provide location information in a custom field. We only load this when necessary. It would be highly unusual for a form taking payment to need this. It is usually only needed in the questions form when a question asks them to locate something on a map. SRI checked, even though loaded locally |
| /locutus/strtotime.js | A utility to provide date arithmetic. Javascript’s date arithmetic is limited; this script provides a function strtotime which mirrors the equivalent on Unix systems. SRI checked, even though loaded locally |
| /panzoom-4.5.1/panzoom.min.js | A utility to allow pan and zoom on a section of the page. This is currently only used in the booking form, and only then when selecting reserved seating, to pan and zoom the seating plan in order to select seats. The seating plan would otherwise be impossible to use on small screens. SRI checked, even though loaded locally |
| https://js.stripe.com/… | Various scripts from this URL that actually implement the payment form for Stripe, StripeCheckout and Applepay |
Changes
In Cameo version 11, changes will have version numbers. Currently scripts do have version information. You’ll see this in the URLs of the scripts loaded. However, it is different for different installations of Cameo. Therefore, so we’ll just quote the date of the change here for now.
| Date of change | Version | Nature of change | Affected Scripts (see above for what these scripts do) |
| 24 March 2025 | Add Sub-resource Integrity checking to utility scripts (not strictly necessary, as they are not loaded from a third-party site, but adds a little additional security). | All /form-name.js | |
| 20 March 2025 | First documented here |