I'm trying to get my website as secure as possible. I'm reading about headers and I should add a Referrer-Policy. However, I'm not sure to understand how this header can make my website more secure.
To be honest, I'm not sure to know how it works. I think the browser get as referrer the previous link.
My website use HTTP not yet HTTPS and I don't know which referrers should I use. I think the default is Referrer-Policy: no-referrer-when-downgrade, but my website use HTTP so that's useless.
its been a while utile you ask but your best answer is here
and according to this blog its how Referrer-Policy works :
When
a user clicks a link on one site, the origin, that takes them to
another site, the destination, the destination site receives
information about the origin the user came from. This is how we get
metrics like those provided by Google Analytics on where our traffic
came from. I know that 4,000 users came from Twitter this week because
when they visit my site they set the referer[sic] header in their
request.
in simple word, it's about users privacy!
Related
Lets say I have my website named SiteA.com running on an Apache web server. I have defined the ff. below on my httpd.conf file:
Header set Access-Control-Allow-Origin "CustomBank.com"
Questions:
Does this mean only CustomBank.com can access my site (SiteA.com) directly? or does it mean only my site (SiteA.com) can access the CustomBank.com domain directly? I am confused if this setting is for inbound or outbound.
In reality I don't have any CORS requirement needed for my site, so I didn't implement the setting mentioned above, the one below shows up in my response header.
Access-Control-Allow-Origin: *
Penetration Testing team said this setting is overly permissive. Do I just need to remove it? if not what should I do?
It means javascript loaded from CustomBank.com can make requests to your site (the site whose configuration has changed) via XMLHTPRequest in the background.
Since XMLHTTPRequest will send a users existing session cookie with your site, malicious scripts could do all kinds of nefarious/misleading things on behalf of your user. That's why * is not normally a suitable fix.
The restrictions apply to other script-like invocations that are more esoteric that you can read about in the specs.
I just setup Google PageSpeed Insight into my Google Webmaster but whenever I am trying to do PageSpeed Test this error occurs "The referrer https://www.googleapis.com/ does not match the referrer restrictions configured on your API key. Please use the API Console to update your key restrictions."
I already created API for my URL and Created Restriction of HTTPS Referrers and submitted my Website in it but still not working.
Any solution for it?
You have set your restrictions incorrectly, the error message points you directly to the problem.
Remove all restrictions and try again, then slowly add restrictions until you reach the problem.
If you have restricted Accept requests from these HTTP referrers (web sites) (Optional) then bear in mind you have to verify your site first for some APIs to function correctly.
I'm implementing the login using google+ account in my website. For this I used the google plus api and while singin google + I got "Error:404 origin miss match". But I provided the right origin like my localhost url.Please suggest to me.
Thanks in advance.
You likely haven't set up the origin in the API console for your client ID. Make sure on the API console (https://developers.google.com/console) that the Javascript origin matches what you're using (including port number!). Note that this is different from the redirect URL - you may have set one, but not the other.
As Satal suggests though, posting some code if you still have problems would help - but I would definitely check you are using the client ID setup with the origin you expect.
So I finally got a link in my facebook post using the properties parameters. I thought I could put my url scheme in there. But unfortunately it says it isn't a valid url, which makes sense. So I searched again for another solution. But everyone seems to be talking about fb:// and not their own app url scheme.
So I created this thread, hope somebody can help me.
Try using bit.ly (or some other URL shortener).
The last time I tried, bit.ly accepted any URI schema and just did a redirect. I've successfully used this in the past to work around inputs that expected either an HTTP or HTTPS schema.
Additionally, similar logic could be done on your own server if you prefer. Simply share a link to your own server on Facebook, and have your server side script do a 301 to whatever App specific URI you have.
Whenever I login to one Google service, I am automatically logged in all their other websites on different domains.
What I want to know is how they are able to access the disparate cookies and sessions that belong on another domain.
I tried searching online but I couldn't find any information. I could probably pull out firebug and try to find out but I am sure someone here knows.
A Google Login works like this:
1) You login, normally at a login page that is under the Google.com/accounts domain.
1a) If you aren't on the Google.com/accounts domain, it is going to forward you there after you post the form. This can be found on sites like Blogger.
Once you arrive at the Google.com/accounts domain, they do two things
2) They set a cookie(s) that is specific to the Google.com/accounts domain, that are also only able to be sent over a secure connection. This is to verify your identity later on.
I say multiple because there are several cookies bound to the google.com/accounts domain. I believe that one of these is to make sure that all doesn't fail if secure connections aren't allowed
3) They set a cookie that spans all the domains using .google.com as their domain, because this will make the cookie available to any domain.
4) They forward you back.
5) If it is a site on a different domain, like blogger, they send along an authorization key in the URL. The page sees it, verfies it, and sets the cookie for a different domain. A technique like this can be seen using Google's Oauth.
Here is where that Secure Cookie comes in.
If you notice, whenever you go to a site after you close your browser, they forward you to the google.com/accounts path, where they reverify you under a secure connection, and then reset the subdomain-wide cookie. Then they send you back.
Furthermore, some sites like Google Adsense use the same technique as Google.com/accounts uses, by making a secure cookie on a specific path, and then using more global cookies to allow greater access.
Some of this is guessing, but given what a non-insider can see, I believe that is close to the truth.
Note: I literally spent like an entire month just browsing from Google Site to Google Site seeing how they did stuff. By upvoting this post, you are decreasing the sadness I have for having no life