I've seen some conflicting information about this. Is there any benefit these days with most web apps being served over https, putting an api key in the header vs as a parameter in a URL???
I had someone freak out about it and my understanding is that it makes no difference over https.
Related
I reading an article about reverse-proxies. Among the benefits listed are
Enable HTTPS support
Gzip responses
I am wondering if I should concern myself with these if I am leveraging Firebase Hosting? I wasn't able to find any information on these topic within their documentation. In short, do I need a reverse-proxy with Firebase hosting?
Firebase Hosting already uses HTTPS, and Gzips most responses.
Even if it didn't, there is no requirement to have HTTPS and/or Gzip. If you don't know whether you need them, you probably shouldn't spend time on adding them.
I have two websites at the moment.
admin.example.com
api.example.com
The "admin" one has all the security headers recommended by https://securityheaders.io.
The "api" has none, which is deliberate. I know that this application will only serve JSON and is a relatively simple API.
Is this bad practise? Do the headers protect against any issues for a API-only site?
I already have HSTS headers set in both scenarios, which is obviously important.
It depends on requiremt of API ,if API is transactional then go with HSTS headers else don't .If API is not containing sensitive data then don't use it .
HTTP Strict Transport Security (HSTS) :
Let’s say you have a website named api.example.com and you installed
an SSL/TLS certificate and migrated from HTTP to HTTPS. But this isn’t
where the work stops. What if your website is still available over
HTTP? It would be utterly pointless, right? Many website admins
migrate to HTTPS and then forget about it without realizing this. This
is where HSTS enters the picture. If a site is equipped with HTTPS,
the server forces the browser to communicate over secure HTTPS. This
way, the possibility of an HTTP connection is eliminated entirely.
Suppose my website is over HTTPS and I need to load a CSS or Object resource from HTTP, how can I do this?
Please note that I'm able to add Content-Security-Policy to the response headers over the HTTPS websites but I don't exactly know how can I do this. Can someone give me a solution?
There is no solution. Modern browsers will deny using non-https resources into pages served by https because you effectively undermine the security model of https this way. CSP will not help because it does not fix the issue. Your only choice is to either serve the site by http or to proxy includes from external non-https sites by your own site. But note that the latter option might affect the security model too, because now these external resources are seen as originating by the same domain as your own content and thus could misuse the same origin policy.
I would like to implement REST APIs with the OAuth protocol for my web service. However I noticed that you must send datas over the internet that give the correct permissions to users.
The question that arose spontaneously is: how much is it insecure to send data without an HTTPS connection?
Any data not sent over https is ripe for being collected by some third party router between the web server and the end client.
Incidentally, you can use HTTPS with RESTful services.
Using OAuth 1.0 or 1.1 without HTTPS may well be insecure (although it was made to be used this way because of extra precautions taken when getting tokens and authorisation), but using OAuth 2.0 (the one used by facebook and most stuff now-adays) if totally insecure and actually goes against the specification for OAuth 2.0
It should be used and accessed over a HTTPS connection.
I'm interested in hearing what others do when, in a given application, some pages need to be secure and others don't. Take any solution off the table that requires a separate domain/subdomain. In this case, all calls, secure or insecure, will link to the same domain. I see a few options:
The ham-fisted, just secure it all approach.
A URI rewrite solution that ensure the pages that need to be secure are accessed via the https protocol and either ignores other pages or, alternatively, forces those to standard http
An application-centric approach where each link is responsible for knowing whether it's pointing and applying the correct protocol. In this solution, all links would have to be fully qualified.
A laissez-fair version of the application-centric approach where links to secure pages are fully qualified and links to other pages are not. In this case, the protocol would be inherited for pages not handled explicitly and inconsequential pages may be accessed via https.
I've used several of these from time to time, but they all have drawbacks. What's everyone else doing in these situations? Is there another path I haven't considered?
UPDATE:
vartec's answer below made me realize that I'd left out one critical piece of information. In my network config, all SSL-handling is taken care of at the load balancer level. The LB, then, communicates with the web server cluster via port 80. As a result, the applications themselves have no idea whether traffic arrived securely. All they see is a port 80 connection.
Thanks.
I use a mixture of #4 and #2: try to specify absolute URLs where possible when I need to switch protocols, and implement server-side redirection to catch any links I haven't used absolute URLs on (or if someone accesses the URL directly, not by following a link).
In my view, the one essential thing is that the pages which need to be accessed securely (form submissions etc.) are accessed securely, and for that I use Apache's SSLRequireSSL directive. It makes it easy to verify to myself that certain pages will never be accessed except over SSL.
I'm for the ham-fisted secure it all approach, but then you took my real solution off the table by (strangely to my mind) excluding domain/subdomain solutions. Errors in securing the site are far more dangerous than a bit of processing overhead.
We have our main site, which is insecure (but mainly marketing) and then we have the application site which is a different subdomain. Simple, easy and effective. Why take that option off the table?
Application centric approach, where controller for each page knows if it has to be secure. If it needs to be secure, but it's accessed via insecure http, redirect to https, passing along all of parameters.