Published on

MITM (Man-In-The-Middle) Attacks and Prevention


Learn how man-in-the-middle (MITM) attacks can put your website users in danger and how to prevent it.

What are MITM attacks?

In a MITM attack, someone on the network intercepts the network communications between a user and your website.

mitm attack

How are MITM attacks made?

There are multiple ways to hijack someone's network connection, but two standard methods are ARP poisoning and evil access points.

ARP poisoning

Hosts on a network talk to the world outside of the local area network (LAN) through a gateway. The gateway is configured on the client, either manually or through the DHCP protocol.

Communication within a LAN, however, is facilitated through MAC addresses, not IP addresses. For this reason, we need a protocol to map IP addresses to MAC addresses to communicate with hosts on the network by their IP address. And this protocol is aptly named address resolution protocol or ARP for short.

Here is how the ARP poisoning attack works.

The attacker sends an unsolicited ARP reply to the target network device (e.g., the website user's phone), claiming that the attacker's device is the gateway. And the way network protocols are implemented, the phone will believe the attacker and start sending its traffic through the attacker's device.

arp poisoning attack

Evil access points

The second typical attack works by the attacker setting up a WiFi access point that mimics a real access point nearby.

When users unwittingly connect to the malicious access point, their network traffic is sent to the attacker, who then forwards it to the Internet.

evil access point


Once the connection has been intercepted, the attacker can use a tool such as sslstrip to disable all HTTPS redirects and change https:// links to unencrypted http://.

It shouldn't matter

The key takeaway here is that developers cannot base an application's security on the assumption that no-one can intercept the connection between the user and the webserver.

Instead, we have to use encryption to make sure it doesn't matter whether the connection is hijacked or not.

Does HTTPS prevent MITM attacks?

Unfortunately, HTTPS alone is not enough to prevent MITM attacks against your users. Let me show you what I mean. The following is generally what happens when a browser connects to a website:

1. The user types in to the URL bar and presses enter.

entering in the URL bar

2. The user's browser sends an unencrypted HTTP request to

unencrypted http request

3. The webserver returns a redirect to

redirect to https

4. The user's browser sends an encrypted HTTPS request to

encrypted http request

5. The webserver returns with the login page.

encrypted login page

6. The user enters their username and password, which the browser safely sends to the webserver across a secure TLS connection.

encrypted login request

But what if there is an attacker on the network?

1. The user types in

entering in the URL bar

2. The user's browser sends an unencrypted HTTP request to

unencrypted http request

3. The attacker intercepts this unencrypted request and returns the login page from the real server. Crucially, the connection is still unencrypted.

unencrypted http request

4. The user gives their username and password straight to the attacker over the unencrypted connection.

unencrypted http request

See the problem? The web server never got a chance to redirect the user to HTTPS because the attacker had already taken over the connection.

How to prevent MITM attacks?

There are three key requirements for protecting your web application from MITM attacks:

  1. Use HTTPS.
  2. Use preloaded HSTS.
  3. Harden your SSL/TLS ciphers.


The first defence is simple, and hopefully you are already doing this. Get a free certificate from Let's Encrypt and use HTTPS for all your content.

Use preloaded HSTS

HSTS (HTTP Strict Transport Security) is an opt-in browser security feature that prevents browsers from making any unencrypted connections to a domain.

The following is how the network flow might work with HSTS enabled:

1. The user types in

entering in the URL bar

2. The website uses HSTS, so the user's browser right away sends an encrypted HTTPS request to The attacker doesn't get a chance.

encrypted http request

3. The webserver returns with the login page.

encrypted login page

4. The user enters their username and password, which the browser safely sends across a secure TLS connection.

encrypted login request

See how HSTS prevented the attack? The browser never sent the first unencrypted HTTP request, and the attacker had nothing meaningful to intercept.

You can enable the protection for your website with the Strict-Transport-Security header. Make sure to include subdomains and enable HSTS preloading. You can read more about the options and what preloading means here: HTTP Strict Transport Security (HSTS).

Harden your TLS ciphers

You can use preloaded HSTS to force connections to your website to be encrypted. But what if someone breaks that encryption? You have to be careful when configuring the TLS settings on your server.

Implement forward secrecy

One of the most important things is to use a key exchange algorithm like Diffie-Hellman that doesn't involve transmitting the symmetric key over the network. Otherwise, such as when using RSA for key exchange, if someone in the future gets access to the private key (remember heartbleed?), the attacker can decrypt all of the past encrypted connections.

This property is called forward secrecy or perfect forward secrecy. Make sure you have it enabled.

Use authenticated encryption

Use cipher suites that verify the authenticity of a message before trying to decrypt it. This way is much less prone to all sorts of attacks like padding oracles. AES-GCM and ChaCha20-Poly1305 are such good ciphers.

Disable legacy protocols

It's important not to support legacy protocols because an attacker on the network can downgrade the connection to the worst settings supported by both the client and the server.

  • Only support TLS 1.2 and up.
  • Only support SHA and SHA2 (SHA256, SHA384, etc.) for the MAC (Message Authentication Code).
  • Only support AES-GCM from block ciphers and ChaCha20-Poly1305 from stream ciphers.

You can check the browser support for TLS 1.2 here.

Generating a secure configuration

Visit Mozilla's SSL Config to generate a secure configuration for your webserver.


The users of any web application can be targeted with MITM attacks even if the website uses HTTPS. Luckily developers can take some measures to protect an application from these attacks. These are:

  • Use HTTPS.
  • Use HSTS and preload it.
  • Configure your server's TLS settings appropriately.