Let's say we have a site
www.coolstore.com
that accesses
api.coolstore.com<p>What is the best practice and possible attack vectors when not sticking to them?<p>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?<p>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?<p>Is there some manual of best practices with deploying react site + api ?
<i>Everything</i> (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.<p>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.<p>Don't mix hostnames - do coolstore.com/api instead - that frees you from cross-origin security issues.
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).<p>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.<p>It's conceivable that at some point every resource loaded on an HTTPS page will require HTTPS, too.<p><a href="https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...</a>