In my own vscode extension, I have implemented my own TreeDataProvider and my own TreeItem.
I want to set Icons on my TreeItems.
A possible type of iconPath of TreeItems is Uri.
When I try to set an http://my.site/my/icon/Icon.svg Uri to my TreeItems, I've got an execution error with the following message : "Content Security Policy of your site blocks some resources, Resource http://my.site/my/icon/Icon.svg is blocked for directive img-src"
How to set a Content Security Policy for Uri in a vscode extension (I'm not in a Webview, I'm in a Tree) ?
Is it possible to set http... icon paths for TreeItems ?
Best regards,
You cannot set your own CSP outside of a webview. The tree can only show icons from trusted websites or from local file system.
Unfortunately I cannot find the place in the documentation where this is mentioned. I only remember that Github is one of the trusted sources.
Related
I have an application that has a VueJs based front end and NodeJs based backend API. The client-side is a SPA and it communicates with API for getting data. Now in a security scan, it is mentioned that the app doesn't have a Permission-Policy HTTP header and I would like to add it. I but not sure is there any option I can add in the VueJS and I am confused whether this is something that needs to be added from the front end. From the Node app, it is possible to set the header, but here the pages are not generated from the server-side. It will be helpful if someone can let me know how can I add these headers to the app.
Technically you can publish Permissions-Policy header when you sent an initial SPA's HTML code (you have to use some packages or Node.js server facility to publish response header). Even more so scanners do not execute ajax and will not see the pages of your SPA.
But there are some doubts whether it is worth doing it at all.
Permissions Policy is a new name of Feature Policy, below I will use Feature Policy term, but all of the below also applies to Permissions Policy.
Browsers poorly support Feature Policy and do not support Permissions Policy. Only Chrome supports the interest-cohort directive, but you have to set specific flags to enable Permissions Policy support. Feature Policy / Permissions Policy spec still is under development.
Feature Policy is rarely published via HTTP header, because it is intended to restrict the capabilities of nested browsing contexts (iframes), and not the main page itself. Therefore it's mostly published via <iframe allow="..." attribute for each third-party iframe embedded.
But the scanners are not aware of this and do not check the allow= attribute.
Scanners don't know much about real security, they are more focused on visualization baubles like Grade A+ and labels with green/red color. Therefore scanners:
are not recognize Content Security Policy in meta tag, just in the HTTP header.
require X-Frame-Options header for any web page despite presence of CSP's frame-ancestors derictive and ignore fact that some sites are inbtended to be embedded (widgets, youtube/vimeo video etc.).
require Feature Policy / Permissions Policy header despite these are not supported or are published by another way.
Mostly scanners results have nothing with real security, all is how to get A+ grade, nothing else (see a relevant thread "headers manipulatin to get Grade A+").
Of course, scanners can draw your attention to some overlooked headlines, but final decision which headers do web-app need to publish is up to you.
The help section of Caching -> Configuration -> Caching Level says:
Note: By default, Cloudflare does not cache HTML content. You can create a Page Rule to cache static HTML content.
I have no page rules set yet. But when I goto Analytics, I see there are 600+ cached requests. Anybody know what happened here?
As the note says "By default, Cloudflare does not cache HTML content.". That means your .html files are not cached but other assets like images, javascript or fonts are.
Here a list of filetypes that will be cached by default:
https://developers.cloudflare.com/cache/about/default-cache-behavior#default-cached-file-extensions
I'm trying to add a test coverage badge to the Readme of a private repository on GitHub. Our continuous integration process saves out the image to a secured Google Cloud Storage bucket that's not accessible to the public, and should remain that way.
Google's authorization layer is smart enough that if I go to the URL for the image, I'm automatically redirected to the resource with a valid auto-generated signed URL.
E.g., if I go to http://storage.cloud.google.com/secret-files/mysecretfile.png, then if I'm logged in and allowed to view it, I'm automatically redirected to something like https://blahblah-apidata.googleusercontent.com/download/storage/v1/b/secret-files/o/mysecretfile.png?key=verylongkey, where I can load the image.
This seemed perfect. Reference the canonical path in the GitHub Readme, authenticated users see the image, unauthenticated users are still blocked, we don't have to make the file public, and we don't have to do anything complicated.
Except that GitHub is proxying the image request, meaning that it will always be unauthenticated. My browser is loading something like https://camo.githubusercontent.com/mysecretimage.png.
Is there a clever way to work around this? Or do I need to go back to the drawing board?
All images on github.com are proxied using the Camo image proxy. There are a couple reasons for this:
It preserves the privacy of users. It isn't possible for a document to track users by directing them to a different site or using cookies to track them.
It means images can be cached and served at an appropriate size.
GitHub can have a very strict content security policy that does not allow loading from untrusted sites, which means that any sort of accidental security problem (like an XSS) is a lot less likely to work.
Note the last part. Even if you found some sneaky way to get another image URL to render properly in the website, your browser wouldn't load it because it violates the Content-Security-Policy header the site sent, and moreover, your browser would tattle about that to the reporting URL that GitHub provided.
So any image URL you provide will need to be readable by GitHub's image proxy and it won't be possible to serve different content to different users.
I went to Twitter's resource page here (https://twitter.com/about/resources/tweetbutton) and got the following code:
Tweet<script type="text/javascript" src="//platform.twitter.com/widgets.js"></script>
When I put this in my Wordpress template, I don't get the Twitter button -- I just get the text "Tweet". However, when I change the src for widgets.js to include https:// or http:// at the beginning it works.
Could it be that it's just an error that they forgot the protocol? Also, do you think it is better to use https (for consistency with the share link) versus http, or does it not matter?
Thanks for your suggestions.
The URL "//example.com/script.js" tells the browser to open the URL using the protocol of the current page, which is likely to be "file://" if your browser opened an html file on your own machine. Of course, you don't have a file called "file://example.com/script.js" on your computer.
In the past, urls for embedded widgets used to include the protocol (http or https), but a site visitor would receive warnings whenever a secure page loaded a script from an insecure page, and sometimes even vice versa. Now, widgets from Twitter, Google Analytics, and other sites no longer specify the protocol so that the same embed code can work on any page on the internet. The downside is that this does not work when you embed such a widget into a file and view it on your own browser by double-clicking it!
I am seeing the "This Page contains both secure and nonsecure items." message when viewing a page on my site from with IE 6. This does not appear in both IE 7 or Firefox. I have done some research and it appears that the problem has to do with links to HTTP:// rather than HTTPS://
Would the fix just be to view the page source and find everywhere there is an HTTP:// src and change it? I believe they are being generated from JavaScript.
Thanks Nick
Yes, you need to make sure that scripts and images are referenced via HTTPS, if the page is referenced by HTTPS.
Alternatively, try using relative URLs, so that your page can be either HTTP or HTTPS without requiring the html to change.
Are you running prototype.js?
There's a line in there to detect when the page has loaded which calls \: as a src=
Replace this src with a js file on your system. It can be blank.
SO the problem was that a 3rd party control was creating an element with and attribute src="about:blank". In IE6 this src is not trusted. The resolution for me was to create a blank.htm file. This file contained nothing but an tag.
I then set the
This fixed the issue. From what I have read, this is not a problem in newer versions of IE.