1

I know HTTP is insecure because the data transmitted is not encrypted.

I made a web application, however, that the frontend and backend are hosted on different servers. The backend itself is configured with HTTPS, but the frontend is not yet (so only HTTP). Every request I make to the backend is made using the HTTPS server.

So this got me thinking: If my "insecure" frontend only uses the sensitive data to make requests to an HTTPS server, doesn't it make my application secure? Because the sensitive data is not transmitted in anyway to the frontend HTTP server, it is merely a static webpage.

And on the other hand, if the situation was reversed: being HTTPS configured on my frontend (thus, it appears as a secure application on the user side, on the browser), but the API endpoints are HTTP. Doesn't it make the application insecure, even though it is an HTTPS website? Because sensitive data would be transmitted to eg http://myinsecureapi.doamin.com.

Improve this question

3 Answers 3

Reset to default
3

When serving interactive content over unencrypted HTTP, nothing prevents the interactive content being tampered with. For example, a HTML form could be manipulated to POST the content to an entirely different server, rather than to your HTTPS backend.

Thus, for your web application as a whole to be secure, you must also serve the frontend over HTTPS. Ensuring integrity is most important for HTML and JavaScript resources. However, more passive resources such as CSS styles, fonts, images, and videos could still be used to mislead the user.

Note that modern browsers have various defense mechanisms against using unencrypted connections. By now, all mainstream browsers will show a warning when using an unencrypted website. My browser is configured to use a HTTPS-only mode, and will not load HTTP sites without explicit confirmation. Some browser features are only available in secure contexts. Cross-origin requests are somewhat restricted anyways. Your reversed example (HTTPS frontend interacting with HTTP API) would likely be blocked by the browser's policy against mixed content (possibly also for normal form submission).

Improve this answer
5
  • "For example, a HTML form could be manipulated to POST the content to an entirely different server" but how could this happen? The website is hosted on my own server, wouldn't the hackers need to hack my server to temper with my HTML, or is there another way?
    – Bersan
    Dec 7, 2022 at 13:05
  • 1
    @Bersan Think about MITM attacks, e.g. an untrustworthy public Wifi network over which your web application is accessed. Without the HTTPS certificate, Wifi operator could spoof your site. They could cause the client to see completely different content, or just inject small changes to your HTML. HTTPS doesn't just provide confidentiality, but also authentication and integrity. If the attacker has hacked your server, then HTTPS can't help either.
    – amon
    Dec 7, 2022 at 14:05
  • Interesting, so if HTTP is in place, then if I operate on an untrusted local network, this could be spoofed.. but if the LAN is secure, do I need to worry still?
    – Bersan
    Dec 8, 2022 at 13:46
  • @Bersan If all connections between the client and the server only go over trusted networks, and all participants on those networks are trusted, then encryption might not be necessary. For example, this could be the case for a web application in an intranet. But I would recommend to avoid thinking of any network as “trusted” – instead, zero-trust approaches are now state of the art.
    – amon
    Dec 8, 2022 at 14:18
  • 1
    @amon Also, you REALLY shouldn't do that for a corporate network either. Insider attacks and compromised hardware both happen. With plain HTTP, not only would the attack succeed, it wouldn't even possible after the fact to tell who did it; the attacker would retain all their access. Additionally, if the service is authenticated (even though it isn't encrypted) then the attacker could steal the credentials of legitimate users, and launch new attacks with that access, or frame the victim for the damage. Plain HTTP: Not even once.
    – CBHacking
    Jan 17 at 4:36
3

A rule we all have to remember:

HTTP POST method is mandatory for transmitting sensitive information (eg. passwords, social security numbers...) with HTML forms. When GET is used, form parameters key=values pairs are apppened in response URI, thus creating information disclosure in client browser URI bar, but also in client/server logs.

Encryption is not enough...

In your application, Static pages and related client browser could still be vunerable to other kind of attacks, mainly related to injection of browser interpretable content, for example browser scripts with XSS, HTML/CSS code...Be aware that those vulnerabilities could be merged together to create more sophisticated attack scenarios.

But Mandatory.

Regardless of services types, services must only provide HTTPS endpoints with corectly configured cipher suites. Your second tough "API endpoints are HTTP" causes a number of problems: it could expose authentication credentials in transit, for example API keys, passwords or JSON Web Tokens. Clients have no protocol handled way of authentication with the service (since you are not using IETF HTTP Authentication mecanisims for this purpose) and the service does not guarantees integrity of the transmitted data.

Consider also the use of mutually authenticated client-side certificates to provide additional protection for a highly privileged web APi.

Improve this answer
1

The rule is that if a service is accessible from uncontroled clients, then that service should be protected by SSL. It does not matter whether well behaving clients use it. What matters is whether they could use it. So if your backend server is publicly accessible, then it should only respond to HTTPS queries when they come from the outside.

That being said, a common configuration is to setup a HTTPS (reverse) proxy (or a farm of proxy servers) that are the only end points publicly accessible. Those proxys then relay the requests and responses to/from the real servers that should be securely hidden behind a firewall. In that case, the real servers could serve HTTP requests without any security problem: all data exchanges occur in a trusted zone. Of course this only make sense when those servers are inside a trusted datacenter, but it is common for companies having private datacenters. Said differently, this should be avoided if the services are hosted on public clouds...

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .