I'm facing the problem of insecure when using caching on Firefox
It's normal when tracking protection is turned off
But we can't ask users to turn it off every time they go to our website
const newCache = await caches.open('new-cache');
I can't open cache by this method
tracking protection turn on
error happen
Access to cache by caches.open() method
No insecure error
Related
I have a script loaded from a 3rd party domain (3p.com) into a webpage (page.com)
The goal is to capture error and unhandledrejection occurring in the 3p script and ping this back to a server for logging.
Whilst there are event handlers available in the browser for this, it seems they do not allow any meaningful collection of information, from the MDN site:
When an error occurs in a script, loaded from a different origin, the details of the error are not reported to prevent leaking information (see bug 363897).
Is there a way to do this? Ideal solution is global and hooks into these events, then allows filtering to only errors from the concerned script. However if would be happy to also wrap the script execution into a try / catch if this would capture all possible errors.
One option would be to set up your server so that requests to that third-party domain get bounced off your server, so that your clients have the ability to programatically examine possible errors that get thrown. For example, instead of serving to your clients
<script src="https://3p.com/script.js"></script>
serve
<script src="https://yoursite.com/get3pscript"></script>
where the get3pscript route on your site makes a request to https://3p.com/script.js, then sends the response to the client, making sure the MIME type is correct. Then the client will be able to do whatever it wants with the script element without cross-domain issues.
We have a legacy website which I'd like to supplement with a chrome extension as a temporary measure.
The site is set up with Spring Security and each request is authenticates with an access token.
I have tried creating an extension that makes a request to the endpoint visible from network requests with the correct data but the endpoint does not respond at all.
Running the same code directly on the website through DevTools gives me a proper response, so I'm thinking the error is due to CORS.
Is there a way to make a chrome extension run code directly on the page so there wouldn't be any CORS issues or should I approach this issue a different way?
We have implemented CSP in our huuuge one-page web app. We keep getting errors time to time and some errors were result of improperly handled user-form inputs and some seem to originate from within user's browser.
Is there a way to harvest more data on client side when CSP exception happens? The server-side report misses vital data. We know source source URL, blocked URL, violated rule/directive... but that is not helpful as we don't know what was on the screen at the moment and if it is user's browser to blame.
We need to know
what javscript module was being viewed at the time/what JS layer/detail
where was the original source/trigger to request that resource - was it our fault of displaying uncleaned form-embedded HTML injected by some robot or was it user's infected browser inserting these malware links?
Is there some hook like window.onCSPException=func that we can hook on and run client-side analysis? We need to distinguish fast our problems from client browser's problems.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#Enabling_reporting:
By default, violation reports aren't sent. To enable violation reporting, you need to specify the report-uri policy directive, providing at least one URI to which to deliver the reports:
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
Then you need to set up your server to receive the reports; it can store or process them in whatever manner you feel is appropriate.
As of January Chrome will show it's users that a site is being insecure if it contains either a password or credit-card field and isn't served via https. (see https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html )
This circumstance raises a little problem:
When you have a web service running locally (for example the web-login page of your router at home ) which is not served with HTTPS since there is the strong possibility that the certificate will expire before the user updates it's software, your user will see this warning.
Mocking the password-field seems too hacky and will likely cause problems on mobile devices.
What would be good alternatives to solve this problem without serving the site with HTTPS?
You should not consider this a problem, but a feature.
If you're running the service on HTTP instead of HTTPS, then your users should expect to be warned about it. Allowing for any exceptions to Chrome`s new rule would be likely to cause uncertainty.
The fact that a site owner is worried a certificate will expire is no excuse: Would it not be preferable to use certificates anyway, and rather risk getting a warning about an outdated certificate instead? That is at least a visible problem that can be fixed fairly easily.
If the new standard implies that a user should be warned about an insecure connection, then hiding that warning means the standard is broken, and that you're providing an false sense of security, which may be worse than no security.
If you want to host a page over an unencrypted connection, that's up to you, but you should probably just accept that the warning will be shown.
When calling the Marketo munchkin.js we are seeing intermittent XHR/CORS errors. This does not happen on every request it is very spotty. Getting into Heisenbug territory.
The specific response from Firefox was:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at XYZ.mktoresp.com/webevents/visitWebPage?XYZ
This can be fixed by moving the resource to the same domain or enabling CORS.
Marketo has informed us that we need to enable CORS on our server for their domain, which we did and we are still seeing issue. The confusing thing is these are GET requests which are allowed without CORS. These are not POST methods, they either specifically call Marketos munchkin.js tracking function visitWebPage (GET), which return in the response a tracking pixel 1x1 png.
The confusing part is we made no server configuration changes on any of our environments, this was confirmed by our SCM. We are seeing this issue on multiple sites on different platforms/hosts. We have also tested the simple munchkin.js calls and the jQuery.ajax calls.
If anyone else in the community is seeing this please let me know.
I am the developer for Munchkin.js at Marketo Inc.
The CORS errors reported by Firebug do not interfere with any Munchkin/Page functionality. They are caused by an optimization in the current version of munchkin which tries to release the XHR connection as soon as it has reported the page activity to Marketo. Firebug mis-reports this as a CORS error. Other browsers correctly report this as cancelled.
We currently planning to remove the optimization in a future release since a lot of customers seem concerned by both the CORS and cancelled messages.