What is a man-in-the-middle attack?

A man-in-the-middle (MITM) attack happens when an attacker secretly positions themselves between two parties who think they're talking directly to each other, such as a visitor's browser and your website. From that position, the attacker can read the traffic, steal passwords or session cookies, and even change the content being sent, all without either side noticing. The main defense is strong encryption with properly validated certificates, which is why HTTPS everywhere matters so much.

MITM attacks are sometimes also called adversary-in-the-middle or on-path attacks, and they range from someone snooping on a coffee shop Wi-Fi network to sophisticated attacks against DNS or email servers. This article explains how MITM attacks work, the most common techniques, what they mean for website owners and visitors, and the concrete configuration steps that keep your site's traffic private and tamper-proof.

What Is a Man-in-the-Middle Attack?

In normal communication, your browser sends a request to a website's server and the server sends a response back. In a man-in-the-middle attack, the attacker inserts themselves into that path. Every message flows through them first.

That position gives the attacker two broad abilities:

• Eavesdropping: Reading data in transit, such as login credentials, form submissions, cookies, and personal information.
• Tampering: Modifying data in transit, such as injecting malicious scripts into a page, changing download links, or altering payment details.

If traffic isn't encrypted, both are trivial. If it is encrypted with properly validated TLS, the attacker sees only scrambled data and can't modify it without the browser detecting the change.

How Does a Man-in-the-Middle Attack Work?

Most MITM attacks have two phases:

1. Interception: The attacker finds a way to get traffic routed through a device they control. This could be a fake Wi-Fi hotspot, a compromised router, manipulated DNS, or poisoned network tables on a local network.

2. Decryption or manipulation: Once traffic passes through them, the attacker reads or modifies it. If the traffic is plain HTTP, this is easy. If it's HTTPS, the attacker has to trick the user into accepting a fake certificate, downgrade the connection to HTTP, or steal something like a session cookie that was sent insecurely.

Modern browsers and HTTPS make the second phase difficult, which is why most real-world MITM attacks look for gaps: an HTTP page, a mixed-content script, a missing security header, or a user who clicks through a certificate warning.

Common Types of Man-in-the-Middle Attacks

Rogue Wi-Fi and Evil Twin Hotspots

An attacker sets up a wireless network with a believable name, such as "Airport Free WiFi" or the same name as a café's real network. Devices that connect route all their traffic through the attacker's hardware. Public Wi-Fi without encryption, or with a shared password everyone knows, is the classic environment for this.

ARP Spoofing

On a local network, devices use the Address Resolution Protocol (ARP) to map IP addresses to hardware addresses. In ARP spoofing, an attacker on the same network sends fake ARP messages claiming to be the router. Other devices then send their traffic to the attacker instead. This requires local network access, such as being on the same office or hotel network.

DNS Spoofing and Hijacking

DNS translates domain names into IP addresses. If an attacker can manipulate DNS responses, they can send visitors to a server they control when the visitor types your domain. This can happen through a compromised router, a poisoned DNS cache, or a hijacked domain registrar account.

SSL Stripping

SSL stripping targets the moment when a user types a domain without https://. The browser's first request goes over plain HTTP, and the attacker intercepts it, connecting to the real site over HTTPS themselves but serving the user an HTTP version. The user sees no padlock but may not notice. HTTP Strict Transport Security (HSTS) is designed to stop exactly this.

Fake or Improperly Validated Certificates

An attacker can present their own certificate for your domain. Browsers will show a prominent warning because the certificate isn't signed by a trusted authority, but some users click through anyway. Apps and scripts that disable certificate verification are even more vulnerable because there's no warning at all.

Session Hijacking

Rather than stealing a password, the attacker steals a session cookie. If a cookie is ever sent over HTTP, or is readable by JavaScript and the site has an XSS flaw, the attacker can replay it to impersonate the user without logging in.

Email Interception

Email servers talk to each other over SMTP. If the connection between them isn't encrypted, or encryption can be stripped, messages can be read in transit. Standards like MTA-STS help enforce encrypted delivery between mail servers.

Browser-Based Attacks (Man-in-the-Browser)

A related variant is malware on the user's own device that sits inside the browser and modifies pages or transactions. It's technically not on the network path, but the effect is similar. Defending against it relies on device security rather than server configuration.

What Can a MITM Attacker Steal or Change?

For a website, the risks include:

• Login credentials for admins and users, if a login page or form is ever served over HTTP.
• Session cookies, allowing account takeover without a password.
• Personal data submitted through contact forms, checkouts, or account pages.
• Payment details, if checkout pages aren't fully secured.
• Injected content, such as ads, malware, or phishing forms added to your pages in transit.
• Modified downloads, where a file your visitor downloads is swapped for a malicious one.

The same risks apply to you as a site owner when you log in to your hosting panel, WordPress dashboard, or SFTP server over an untrusted network.

How to Protect Your Website From MITM Attacks

As a website owner, your job is to make sure every connection to your site is encrypted, authenticated, and can't be downgraded.

Serve Everything Over HTTPS

Every page, asset, API endpoint, and form on your site should use HTTPS. Free certificates from Let's Encrypt make this accessible for any site, and most hosts provision them automatically. If you still have HTTP pages, migrating the whole site to HTTPS is the foundation for everything else in this section.

Make sure HTTP requests redirect permanently to HTTPS. On Nginx:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

On Apache, in the HTTP virtual host or .htaccess:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Enable HTTP Strict Transport Security (HSTS)

HSTS tells browsers to only ever connect to your domain over HTTPS, even if a user types http:// or clicks an old link. After the first visit, the browser won't even attempt an HTTP connection, which defeats SSL stripping.

On Nginx, inside your HTTPS server block:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

On Apache:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Start with a short max-age (such as 300) while testing, and only add includeSubDomains once you're sure every subdomain supports HTTPS. Once you're confident, you can add preload and submit your domain to the HSTS preload list, which builds the rule into browsers so even the very first visit is protected. Preloading is hard to reverse, so treat it as a long-term commitment.

Use Modern TLS Settings

Disable old protocols like SSL 3.0, TLS 1.0, and TLS 1.1, which have known weaknesses. Support TLS 1.2 and TLS 1.3. On Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

On Apache with mod_ssl:

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

For a complete, current configuration, the Mozilla SSL Configuration Generator produces tested settings for Nginx, Apache, and other servers. You can then check the result with an online TLS scanner such as the Qualys SSL Labs server test.

Fix Mixed Content

Mixed content occurs when an HTTPS page loads scripts, styles, images, or iframes over HTTP. Those HTTP resources can be intercepted and modified, and a modified script can take over the whole page. Modern browsers block or auto-upgrade most mixed content, but you should fix it at the source by updating URLs to HTTPS.

As a safety net, you can ask browsers to automatically upgrade insecure requests with a Content Security Policy directive:

add_header Content-Security-Policy "upgrade-insecure-requests" always;

Secure Your Cookies

Cookies that carry sessions should never travel over HTTP or be readable by scripts. Set these attributes:

• Secure: Only send the cookie over HTTPS.
• HttpOnly: Prevent JavaScript from reading the cookie.
• SameSite: Limit when the cookie is sent with cross-site requests (Lax is a sensible default).

WordPress sets the Secure flag on its authentication cookies when the site is accessed over HTTPS and uses HttpOnly for them. For custom PHP applications, configure it explicitly:

<?php
session_set_cookie_params( array(
    'lifetime' => 0,
    'path'     => '/',
    'domain'   => 'example.com',
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Lax',
) );
session_start();

Or in php.ini:

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = "Lax"
session.use_strict_mode = 1

Force HTTPS for the WordPress Admin

If your whole site is on HTTPS (as it should be), make sure WordPress enforces it for logins and the dashboard. Add this to wp-config.php above the line that says "That's all, stop editing!":

define( 'FORCE_SSL_ADMIN', true );

Also confirm that both Settings > General > WordPress Address (URL) and Site Address (URL) start with https://.

Protect DNS and Your Domain

Because DNS attacks can redirect visitors before HTTPS even starts, secure the DNS layer too:

• Enable two-factor authentication and a transfer lock on your domain registrar account.
• Consider enabling DNSSEC if your registrar and DNS host support it. DNSSEC signs DNS records so resolvers can detect forged responses.
• Add CAA records to restrict which certificate authorities can issue certificates for your domain:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

This reduces the risk of an attacker obtaining a valid certificate for your domain from another authority.

Verify Certificates in Server-to-Server Calls

Your site probably calls external APIs for payments, email, or shipping. Never disable certificate verification in these requests, even if it "fixes" an error during development. In WordPress, wp_remote_get() and wp_remote_post() verify certificates by default; don't pass 'sslverify' => false in production. In plain PHP with cURL, keep CURLOPT_SSL_VERIFYPEER enabled:

<?php
$ch = curl_init( 'https://api.example.com/v1/orders' );
curl_setopt_array( $ch, array(
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_SSL_VERIFYPEER => true,
    CURLOPT_SSL_VERIFYHOST => 2,
    CURLOPT_TIMEOUT        => 10,
) );
$response = curl_exec( $ch );
curl_close( $ch );

Use Encrypted Protocols for Administration

Use SFTP or SSH instead of plain FTP, which sends passwords in clear text. Use your host's HTTPS control panel URL, not an HTTP one. For database administration, connect over SSH tunnels or TLS rather than exposing an unencrypted database port to the internet.

How to Protect Yourself as a User

Site owners are users too. When you manage your website:

• Avoid logging in to admin panels on open public Wi-Fi. If you must, use a trusted VPN or your phone's hotspot.
• Never click through a browser certificate warning on a site you manage. It could be an attack, or a sign that something is misconfigured and needs fixing.
• Keep your operating system, browser, and router firmware updated.
• Change default passwords on your home or office router.
• Use a password manager, which won't autofill credentials on a spoofed domain.
• Turn on two-factor authentication so a stolen password or session isn't enough on its own.

Signs of a Possible MITM Attack

MITM attacks are designed to be invisible, but a few clues may show up:

1. Certificate warnings on sites that normally load fine.

2. Missing padlock or a site suddenly loading over HTTP.

3. Unexpected content such as ads or pop-ups on pages that shouldn't have them.

4. Frequent unexplained logouts or security alerts about logins from unfamiliar locations.

5. DNS changes you didn't make in your registrar or DNS provider dashboard.

If you notice any of these, disconnect from the network, switch to a trusted connection, and change passwords for anything you logged in to.

---

FAQ: Man-in-the-Middle Attacks

---

Conclusion

A man-in-the-middle attack exploits the path between your visitors and your server, letting an attacker read or alter traffic that both sides believe is private. Techniques range from fake Wi-Fi hotspots and ARP spoofing to DNS hijacking, SSL stripping, and stolen session cookies, but they all depend on finding a gap in encryption or validation.

Closing those gaps is well within reach for any site owner. Serve everything over HTTPS, redirect HTTP permanently, enable HSTS, use modern TLS settings, fix mixed content, secure your cookies, protect your DNS, and never disable certificate verification. Pair that with safe habits when you manage your site from the road, and MITM attackers will find very little to work with.