HTTPS website+API, confusion about best practices?

5 pointsepimetheus24y ago8 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 ?

HTTPS website+API, confusion about best practices?

5 pointsepimetheus24y ago8 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?

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 ?

8 comments

6 comments · 3 top-level

emteycz4y ago· 3 in thread

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.

epimetheus2OP4y ago

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?

GauntletWizard4y ago

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.

emteycz4y ago

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.

1 more reply

codegeek4y ago

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.

theandrewbailey4y ago

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...

j / k navigate · click thread line to collapse