HTTPS website+API, confusion about best practices? | Hacker News Reader

HTTPS website+API, confusion about best practices?

5 pointsepimetheus28 comments

Let's say we have a site www.coolstore.com that accesses api.coolstore.com

What is the best practice and possible attack vectors when not sticking to them?

It seems that www.coolstore.com should be under https://www.coolstore.com. What about assets? Let's say we force a redirect to https:// on the site itself, but not on assets. e.g. you copy the request and change it to http you can access some javascript files. Would that be a problem?

How about API ? Is it neccesary that also api.coolstore.com requires https, even though it's only used by the website? Should it have http:// completely turned off?

Is there some manual of best practices with deploying react site + api ?

View on HN

Everything (including links to external sites) should be on HTTPS. Browsers will error if you try to load JS assets from HTTP on a HTTPS site.

Don't use HTTP for API even if you could. Usually servers will return status 301 (client-side redirect) directed to the same URL but using HTTPS to any HTTP request.

Don't mix hostnames - do coolstore.com/api instead - that frees you from cross-origin security issues.

sure, but does it need to be disabled? As in, my website will use HTTPS, but HTTP may be still present. Does that open up door for any attack?

It doesn't as long as you handle the HTTP->HTTPS redirect on your proxy (NGINX, Apache, Caddy or similar) and don't pass any of these requests to your backend.

you can copy curl from browser, change https to http and it will work, is that susceptible? The whole react app uses https

Don't allow any HTTP requests to be passed to your actual backend app, handle them only on the proxy.

For example:

You set up NGINX on ports 80 and 443 and open these ports (TCP for 80 and TCP/UDP for 443) to the internet, and close all other ports. Your backend runs on port 3000, and you configure NGINX to proxy pass coolstore.com/api to said port 3000.

All client-traffic HTTPS is handled on the NGINX proxy (it can also serve your static files very well). Any HTTP requests are sent response status 301 with HTTPS version of request URL.

I'm of the (weak) opinion that if you have www.coolapp and api.coolapp, you should have port 80 closed on api. - don't even serve redirects. Any legitimate traffic would be broken anyway, and it prevents you from even accidentally doing something stupid like serving a cookie without secure, or receiving (unencrypted) a token from a misconfigured client.

Any public facing URL should have https (SSL certificate installed) and any http request should always redirect to https. There is such thing called "SSL Termination" where you may have a public facing load balancer/proxy which works on https but terminates SSL which means that any upstream backend servers under that load balancer are http only (but are not publicly available).

Whether you have api.coolstore.com or not, that is more of a design decision. It is a common practice to setup website and API separate where API is hosted on subdomain. So you could do coolstore.com and api.coolstore.com but install https on both and setup http->https redirect to both.

HTTP to HTTPS (and vice-versa), even on the same (sub-)domain, is automatically considered cross-origin. This restricts what HTTPS-loaded Javascript and API calls can do on an HTTP-loaded page. Having everything HTTPS from the beginning will cause less issues in the long run.

It's conceivable that at some point every resource loaded on an HTTPS page will require HTTPS, too.

https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...

Reply on news.ycombinator.com