bhauman 2020-06-15T13:09:21.278300Z

@dominicm apparently some services will reject xhr calls if they come from insecure pages, for example AWSElasticLoadBalancer endpoints that are secured with ssl will reject requests

bhauman 2020-06-15T13:11:05.280300Z

but in general, it seems that most developers use https locally when they actually don’t need to

dominicm 2020-06-15T13:58:21.281400Z

That seems, hmm. How do they even know. Unless it's a layer of security they've manually added. I've never heard of that in OWASP advice or anything.

dominicm 2020-06-15T13:59:52.282400Z

Personally I'd solve this by using a proxy. Rather than messing with trust. I seem to recall using a public one many years ago.

dominicm 2020-06-15T14:00:32.282900Z

Let's encrypt article is great on this: > Fortunately, modern browsers consider to be a “potentially trustworthy” URL because it refers to a loopback address. Traffic sent to is guaranteed not to leave your machine, and so is considered automatically secure against network interception. That means if your web app is HTTPS, and you offer a native app web service on, the two can happily communicate via XHR. Unfortunately, localhost doesn't yet get the same treatment. Also, WebSockets don't get this treatment for either name.

dominicm 2020-06-15T14:00:39.283200Z

Looks like the ip gets a free pass.

dominicm 2020-06-15T14:02:00.283700Z

(Doesn't really help here, totally unrelated)

bhauman 2020-06-15T15:54:43.284300Z

that’s definitely interesting about