I want to allow external sites to embed iframes from my site.
I have setup Content Security Policy using frame-ancestors (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors).
Sites that need to be allowed are of format:
example.com
subdomain1.example.com
subdomain2.example.com
Is it enough to set iframe-ancestors using wildcard:
frame-ancestors *.example.com
Or do I need to explitly list the example.com too:
frame-ancestors *.example.com example.com
Spec says: http://*.example.com: Matches all attempts to load from any subdomain of example.com using the http: URL scheme.
I'm not sure is example.com considered as such subdomain too in this context.
Related
The situation is following.
My client have a domain example.com. I can access to the site with the following urls :
example.com
www.example.com
http://www.example.com
But I cannot access the site with http://example.com.
Do anyone know why this happens?
I have a simple website host that gives me a domain like website.com which show the website hosted on that server.
I have a CNAME on website.com that redirects to server.cloudapp.net (Azure Virtual machine running Linux)
server.website.com redirects to server.cloudapp.net.
I need to access the user camera on Chrome, and for that, the website need's SSL.
I can purchase a SSL certificate for website.com, but would it work on my cname?
The certificates subject must include all names you see in the URL in the browser. Thus is you have a CNAME aliasing foo.example.com to bar.example.com than foo.example.com will be the one visible in the URL and you must have the certificate for it.
Note that CNAME is just an alias and not a redirection. With a redirection (i.e. HTTP status codes 30x) the URL would change, while with a CNAME it does not.
Is there improved security with web applications if you use "Require SSL" in the SSL Setting section of IIS? I was planning on creating a URL Rewrite rule.
"Require SSL" will cause a 403.4 Forbidden response if you try to access the site using http://example.com. It won't automatically redirect to the https:// url.
This may be confusing for users if you're not linking in some way to the https://example.com SSL'd url.
If you want users to be able to randomly hit the site using plain http:// and then redirect them to the SSL'd url then you're better off leaving "Require SSL" turned off and do a rewrite.
every page domain begin with http:// or https:// no matter what. but in some web page there is no www after that, while others have it. Is it up to me having it or not. when can i decide that?
amazon have it http://www.amazon.com/
while no tumblr page haven't one http://f-l-e-u-r-d-e-l-y-s.tumblr.com/
note: tumblr hasn't www because it has subdomains?
It's up to you indeed.
In http://www.amazon.com/, amazon.com is the domain name.
http:// or https:// define the protocol (https = secured http). It's not part of the domain name.
www is a subdomain. you may have multiple subdomains for a given domain - or no subdomain.
I have server, running some number of sites.
For example: example.com a.example.com b.example.com
All sites are routed via nginx to unix domain-sockets.
Each of sites is gunicorn instance.
Can applications from subdomains read/write cookie data from example.com or from other subdomains?
If yes, how to disable it?
Sure, you can use separate cookies for the subdomain. The Cookie standards allow you to set a domain, which will be the only domain that browsers will send the cookie back to. You can set "a.example.com" as the domain, and browsers will only send cookies from that domain back to that domain.
From my reading of RFC 2965 for cookies, "a.example.com" cannot set a cookie for "b.example.com", only "example.com".
I think the bottom line is to be sure that you are are using the "domain" property of cookies to set cookies for the subdomain, and not just "example.com", which all subdomains could read and write to.