When displaying JS errors in the Error Analysis feature the top error might be "Script error".
Contentsquare collects errors via web browser, however the majority of browsers don’t share the details of an error coming from another domain (function name, file, etc.) unless they are allowed to.
That’s why, for some errors, Contentsquare can only report “Script Error”, as it is a setting coming from the browser and the hosting server.
Managing which scripts to unmask
Work with your developer(s) to understand which JS errors they are struggling to reproduce and fix.
You can create a spreadsheet to list your 3rd party providers* and keep track of which scripts have been unmasked with the cross-origin attribute.
*Please note some 3rd parties can’t be unmasked E.g. Google, Meta or Adobe.
How to unmask script errors
| Note: This process will require help from your developer. |
1. Add Access-Control-Allow-Origin HTTP header on the script:
Access-Control-Allow-Origin
2. Configure the response header to:
Access-Control-Allow-Origin:*
The server will indicate to browsers that any origin can fetch this file.
3. Add the attribute on the script tag:
crossorigin="anonymous"
Javascript version: script.crossOrigin="anonymous" (E.g. For the GTM async loader). This code tells the browser to fetch the target file anonymously so that no sensitive data is forwarded via cookie or HTTP authentication.
⚠️ This must be done only on the scripts on which the header sent authorized cross-domain (step 1 above!).
FAQ
Why should I unmask script errors?
If you have some JS errors that your developers are struggling to reproduce and fix, you can unmask them to see the explicit error message. Note: Adding the header “Access-Control-Allow-Origin” will expose the script error message to every third-party script running on your website, not only to Contentsquare.
What will the two instructions above do?
By updating the header (step 1), the server will indicate to browsers that any origin can fetch and inspect this file, including the host. By adding the crossorigin attribute (step 2), it will tell the browser that the target file should be fetched "anonymously". This means that no potentially user-identifying information like cookies or HTTP credentials will be transmitted by the browser to the server when requesting this file.
How long does it take to see the results?
After 3 hours, the Script errors should begin to be replaced by the actual details of the scripts in Error analysis.
What is the security downside?
Regarding step 1, the first thing to keep in mind is that this header is just a HTTP header that is sent from the server to the browser. Limiting it for specific origins or completely disabling the header does not make your website safer if your private resources are not properly protected. In fact, modern browsers take into account the header, but an application like Postman or a robot can simply ignore the header. Note: If you have corrected all errors and you are confident that there won’t be any new one’s then you can choose to mask the script errors. If any new errors occur, you will need to repeat the process. When adding the attribute (step 2), the browser will execute the script normally, but there will be no exchange of user credentials via cookies, client-side SSL certificates, or HTTP authentication unless it is in the same origin. As scripts are static files, they almost never need these features anyway.
How do I tell if an existing file needs an HTTP Header update?
On Google Chrome, open the Developers Tools panel, go to the Network tab and click on the name of the JS file. Under the Headers tab, look for the “Response Headers”. You should see listed “access-control-allow-origin”. Note: You may need to wait for the browser or Content Delivery Network (CDN) cache to be updated.
Who will I need from my team to help unmask Script errors?
Enlist your site's web developer(s) to help prioritize and then unmask script errors.
Share this article with them and read on to learn more!
Why are some errors only reported as "Script Error"?
Contentsquare collects errors via web browser. A majority of browsers don’t share the details of an error coming from another domain (function name, file, etc.) unless they are allowed to. This is the case, for instance, for third-party tools such as Google Analytics’ scripts.
That’s why, for some errors, Contentsquare can only report “Script Error”, as it is a setting coming from the browser and the hosting server.
To fix this, the scripts need to be unmasked to signal they accept to be inspected by tags like ours.
How to unmask Script errors on your own computer
Even though Contentsquare can't access any specific details about the error, if you are able to reproduce it on your own computer you should be able to get more useful information on which errors to unmask first.
Follow the steps below:
1. Open your website on a page that consistently produces errors.
2. Open the Javascript console of your browser (details here)
3. In the console you will see a full unmasked log of all errors on this page.
4. Use the function below to check what the CS Tag is seeing when this error occurs.
window.onerror=function(errorName, file, lineNo, colNo, errStack) {
debugger;
}
If you can't find what you are looking for - check with your site's web developers!
How to unmask Script errors permanently
Step 1. Choose the scripts to unmask
The more Scripts you unmask, the more errors you will be able to collect.
First, you'll need to prioritize scripts to unmask:
- Ask your site's developer(s) They will help you select the scripts that are the most accessible to unmask and collect errors details from and moving forward fix.
- Select scripts from the Error analysis module. Some “Script Errors” point to a specific file, they might be good to unmask if you want more details on them.
- Ask third-party providers to do the same. This way, their JavaScript libraries will be added to your watchlist!
Note: The process of unmasking script errors is a global update, meaning you do not need to wait for new errors to generate before following the instructions below to unmask, this process will unmask all JS errors
Step 2. Add a cross-origin HTTP header on the server of these scripts
The server(s) hosting the script(s) should send this HTTP header:
| Access-Control-Allow-Origin: * |
Who can do this?
This is a server-side action that can be done either by the developers in charge of the website and/or the hosting provider. Share this page with them!
What does it mean?
The server will indicate to browsers that any origin can fetch and inspect this file, including the host.
Do I need to wait for new errors to generate to start unmasking?
No, the process of unmasking script errors using a cross-origin header is a global update, meaning you do not need to wait for new errors to generate before following the instructions below to unmask, this process will unmask all third-party scripts.
Can I use the domain of my website instead of *?
Yes, you also can if you specify the complete origin (protocol, subdomain and domain) where the script will be loaded.
For Example: Access-Control-Allow-Origin: https://www.domain.com and Access-Control-Allow-Origin: https://checkout.domain.com for your "domain.com" website, depending on where the script is loaded.
Is there any security downside?
No. The first thing to keep in mind is that this header is just a HTTP header that is sent from the server to the browser. Limiting it for specific origins or completely disabling the header does not make your website safer if your private resources are not properly protected. In fact, modern browsers take into account the header, but an application like Postman or a robot can simply ignore the header.
How to see the HTTP Headers of a file? [For developers]
- On Google Chrome, open the Developers Tools panel.
- On the Network tab, click on the name of the JS file.
- Under the Headers tab, look for the “Response Headers”
- You should see listed “access-control-allow-origin: *” after the above update or if no change is necessary.
Note: You may need to wait for the browser or Content Delivery Network (CDN) cache to be updated.
Step 3. Add a crossorigin="anonymous" script attribute on these scripts
On the tag(s) calling the file(s), add the following attribute:
| <script src="http://another-domain.com/app.js"crossorigin="anonymous"></script> |
⚠️ This must be done only on the scripts on which the header sent authorized cross-domain (step 2 above).
Who can do this? —This is a server-side action that can be done by the development team in charge of the site. Share this page with them!
What does it mean? —This code tells the browser that the target file should be fetched "anonymously". This means that no potentially user-identifying information like cookies or HTTP credentials will be transmitted by the browser to the server when requesting this file.
Is there any security downside? — No. When adding the attribute, the browser will execute the script normally, but there will be no exchange of user credentials via cookies, client-side SSL certificates, or HTTP authentication unless it is in the same origin. As scripts are static files, they almost never need these features anyway.
Step 4. See the results
After 3 hours, the Script errors should begin to be replaced by the actual details of the scripts in Error analysis.