I'm trying to get realtime data model with gapi.drive.realtime.load method in my Chrome Packaged App :
gapi.drive.realtime.load(fileId, onLoad)
but I'm caught an EvalError:
Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' apis.google.com drive.google.com".
Of courcse, I can just add 'unsafe-eval' to manifest, but I guess it is bad way to solve this problem. Can you suggest better solution ?
A packaged app can't have a less restrictive CSP than the default, so your proposed change to the manifest wouldn't have worked. Instead, create a sandboxed iframe that allows eval(), then message back and forth between the iframe and your app. This is a good example with links to further documentation.
Related
I want to migrate my Chrome Extension to manifest V3.
The content_security policy looks as follows on manifest V2:
{...
"content_security_policy": "script-src 'self' 'sha256-...'; object-src 'self'"
}
Notice that I'm using sha-256 value which is the most specific property.
Furthermore, I performed a "semi-official" converting using this tool.
When I convert the manifest to V3 and then update the extension, I get the following error. I don't understand why it is considered as an insecure CSP value, while it is accepted on Manifest V2 and is considered secure to use the specified hash value of the code.
How can I overcome it?
In manifest MV3, CSP is an object, however in the error it is a string, so it needs to be reformatted.
Example and instructions from migration guide:
Manifest V2
"content_security_policy": "..."
Manifest V3
"content_security_policy": {
"extension_pages": "...",
"sandbox": "..."
}
extension_pages: This policy covers pages in your extension, including html files and service workers. These page types are served from the chrome-extension:// protocol. For instance, a page in your extension is chrome-extension://<extension-id>/foo.html.
sandbox: This policy covers any sandboxed extension pages that your extension uses.
Important!
In addition, MV3 disallows certain CSP modifications for extension_pages that were permitted in MV2. The script-src, object-src, and worker-src directives may only have the following values:
self
none
Any localhost source, (http://localhost, http://127.0.0.1, or any port on those domains)
CSP modifications for sandbox have no such new restrictions.
Going through this guide, it seems having sha-256 values is not allowed for extension pages. But these are typically inlined scripts. You can save the script as a js file, and load it from there using <script/> tag instead; this will not require CSP policy.
I am integrating with a third party library (Chargebee) and I am receiving Content Security Violation errors.
As far as I can tell, I don't have CSP defined in my web page as it doesn't return a CSP response header:
Although, when trying to utilise this library I'm getting errors along the lines of:
Questions
I'm using other third party JS libraries, why am I not getting this error for any others? I've never had to specify a CSP for any previously.
If I do actually define a CSP, I'm then blocking the other third party libraries. Can I allow Chargebee without then blocking others (and without having to include them all in the CSP)?
It doesn't make sense. It suggests that I don't have a CSP defined seeing as it's not returned in my headers and I can use third party resources, I have even verified this using the Chrome CSP evaluator extension. And yet, the error messages show that I do have a CSP policy defined.
Am I missing something?
If I do actually define a CSP, I'm then blocking the other third party libraries. Can I allow Chargebee without then blocking others (and without having to include them all in the CSP)?
No - CSP is an allowlist protocol.
If you define a CSP, you need to map out all the various needed resources - at least for the directives that you are using (for example you can confine your CSP to only script-src and object-src, and ignore others).
Since you cannot control or predict which directives are needed for Chargebee CSP, it's best to use predetermined CSP packages, and a CSP generator.
Before reading past this. I am very new to coding. I am especially new to XMLHTTP requests/Fetch.
I am trying to get the data from a JSON file from an external website that is behind a login. Let's say:
https://example.com/booking-api/api/v1/example-availability
I tried to do a simple fetch within the google chrome console:
fetch("https://example.com/booking-api/api/v1/example-availability")
.then(console.log)
.catch(console.error)
In return I receive this:
adrum-latest.js:30 Refused to connect to 'https://example.example.net/rest/v1/delivery?client=example&sessionId=e331c348a9994242bd32b18588f0483a&version=2.1.0' because it violates the following Content Security Policy directive: "connect-src 'self' *.example.com *.example2.com etc.
How can I fetch the json data from this site? Is there a way around the Content Security Policy directive: "connect-src 'self'?
My end goal is to grab this information every so often. Let's say twice a day.
Remember, I'm not completely sure what I am doing. I have never really looked into these types of requests. Any help or information is greatly appreciated.
Sources *.example.com *.example2.com allow subdomains only and do not allow main domains example.com and example2.com. Use:
connect-src 'self' *.example.com *.example2.com example.com example2.com
I'm calling a SonarQube API using JSONP module.
this.jsonp.get('https://sonarqube.com/api/projects/index')
.subscribe(res => console.log(res));
I previously used Http module of Angualar2, which caused the browser to throw the error
Origin http://localhost:4200 is not allowed by Access-Control-Allow-Origin
To overcome this problem I found out that you could use JSONP or CORS or launch chrome with --disable-web-security of which I could find sufficient typescript support to get started with JSONP. But I later found that JSONP expects MIME-type to be application/javascript when I got the following error
Refused to execute script from 'https://sonarqube.com/api/projects/index' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
Is there a way to force JSONP module to fetch JSON data and parse it successfully?
Solution 1: Enable JSONP in Server
I found out that this isn't possible. JSONP is just one way to get over the Cross-Origin-Requests problem, but it requires a modification to the server configuration/implementation to serve JSONP data (MIME-type: application/javascript).
Solution 2: Enable CORS support in server
CORS is a more recent solution to the Cross-Origin-Requests problem. It can be resolved by adding the following headers to the server:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST,GET,PUT,DELETE
Access-Control-Allow-Headers: Authorization, Lang
Solution 3: Using a reverse proxy
One suggestion I came across in my search was to use the server to fetch the Cross-Origin-Request. I didn't have control over the server code. Then I came across the concept of Reverse Proxies, found the cors-anywhere package in an angular forum. The reverse proxy fetches these resources on behalf of your front-end and adds the CORS headers to the proxied request.
I receive the following errors when loading a local chrome extension:
Refused to load the script 'https://widget.intercom.io/widget/APPID' because it violates the following Content Security Policy directive: "script-src 'self' http://localhost https://widget.intercome.io/ 'unsafe-eval'".
index.html:1 XMLHttpRequest cannot load http://localhost:5000/login. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'chrome-extension://bbmhkchajfbhfjkfiaadlnohbfhbnegj' is therefore not allowed access.
I attempted to put the following line in my manifest.json:
"content_security_policy": "script-src 'self' http://localhost https://widget.intercome.io/ 'unsafe-eval'; object-src 'self'"
Shouldn't this last line in particular allow me access to these two resources?
You have the right idea with the https://widget.intercome.io CSP rule, but you may need to
correct the spelling of your domain name (your error has intercom.io, but your CSP says intercome.io)
remove the trailing slash (I'm not sure, but none of the CSP examples I've found use a trailing slash)
reload your extension after making changes
The localhost error is caused by enforcement of the same-origin policy, not the CSP. (Ajax requests, which are governed by the connect-src CSP directive, are not restricted by Chrome extensions' default CSP.) You need to add http://localhost/* as a host permission in your manifest's permissions field:
"permissions": [
"http://localhost/*",
...
]
To expand on apsillers' answer, for anyone that comes here in the future:
This is correct, but make sure you include it in a separate file. I was running into an inline issue, so I just created a file called intercom.js and then included the script there and in my HTML I include it <script src="intercom.js" charset="utf-8"></script>
Also this is what worked for me:
"content_security_policy": "script-src 'self' http://localhost https://widget.intercom.io https://js.intercomcdn.com 'unsafe-eval'; object-src 'self'"