Why HTTPS Doesn't Mean a Website Is Safe

We've all been told to look for HTTPS when visiting a website.

If the URL starts with https:// and the browser doesn't show a security warning, it's easy to assume everything is safe.

But there's an important distinction that often gets overlooked:

HTTPS protects your connection to a website. It doesn't guarantee that the website itself is trustworthy.

Let's break down why that matters.

What HTTPS Actually Protects

HTTPS stands for Hypertext Transfer Protocol Secure. It uses TLS (Transport Layer Security) to secure communication between your browser and a web server.

Consider these two URLs:

http://example.com/login
https://example.com/login

The first uses unencrypted HTTP. The second uses HTTPS, which protects HTTP traffic using TLS.

When properly implemented, HTTPS provides three important protections:

• Encryption: Prevents someone monitoring the network from easily reading the data being transmitted.
• Integrity: Protects against unauthorized modification of data in transit.
• Authentication: Helps verify that you're communicating with a server authorized for the domain you're visiting.

These protections are essential, especially when transmitting sensitive information such as passwords, payment details, or personal data.

Here's a simplified comparison:

Protection	HTTP	HTTPS
Encrypted communication	No	Yes
Data integrity in transit	No cryptographic guarantee	Yes
Server authentication	No TLS authentication	Yes
Guarantees website is trustworthy	No	No

Notice that last row.

HTTPS secures the communication channel, not the trustworthiness of the website itself.

Even Phishing Websites Can Use HTTPS

Imagine receiving an email claiming that your account needs immediate verification.

The email contains a link:

https://khg5293-login.example

This is a fictional domain used for demonstration.

You click it and find a convincing login page.

The URL uses HTTPS, your browser accepts the certificate, and there are no obvious connection security warnings.

Does that mean the website is legitimate?

Not necessarily.

An attacker can register a domain, obtain a valid TLS certificate, and host a phishing page that looks nearly identical to a legitimate website.

For example, consider these fictional URLs:

# Legitimate website
https://accounts.example.com/login

# Lookalike phishing website
https://accounts-example-login.test/login

Both could use HTTPS. Both could have valid TLS certificates for their respective domains.

But only one might belong to the organization you intended to visit.

When you enter your credentials, HTTPS encrypts the information before transmitting it.

Here's the problem:

Your credentials could be securely transmitted directly to an attacker.

HTTPS is functioning exactly as intended. It simply cannot determine whether the destination deserves your trust.

HTTPS Doesn't Fix Application Vulnerabilities

Even legitimate websites using HTTPS can contain serious security vulnerabilities.

Some common examples include:

• SQL Injection: An application improperly handles user input, allowing attackers to manipulate database queries.
• Cross-Site Scripting (XSS): Malicious scripts execute in users' browsers due to unsafe handling of untrusted content.
• Broken Access Control: Users access resources or perform actions beyond their authorized permissions.
• Server Compromise: Attackers gain unauthorized access to the infrastructure hosting the application.

HTTPS doesn't automatically prevent any of these problems.

Example: An HTTPS Login Request

Consider the following application-level HTTP request:

POST /api/login HTTP/1.1
Host: demo.example
Content-Type: application/json

{
  "username": "khg5293",
  "password": "example-password"
}

When sent over HTTPS, this HTTP message is protected inside an encrypted TLS connection.

A network observer generally cannot read the request body or credentials in transit.

But what happens after the server receives the request?

If the application stores passwords insecurely, has vulnerable authentication logic, or exposes sensitive information through improperly configured endpoints, HTTPS won't fix those issues.

Example: SQL Injection Over HTTPS

Imagine a backend application that constructs SQL queries by directly inserting user-provided input:

// Vulnerable example: never construct queries this way
const username = req.body.username;

const query =
  `SELECT * FROM users WHERE username = '${username}'`;

If an attacker submits a specially crafted username, the resulting SQL statement could behave differently than intended.

For example:

SELECT *
FROM users
WHERE username = '' OR '1'='1';

Depending on the application's database logic, this could cause the query to return records it shouldn't.

And yes, this attack can be delivered over a perfectly valid HTTPS connection.

The solution isn't to remove HTTPS. It's to implement proper application security controls.

For example, using a parameterized query:

// Safer approach: parameterized SQL query
const username = req.body.username;

const [rows] = await db.execute(
  "SELECT * FROM users WHERE username = ?",
  [username]
);

Here, the username is passed as data rather than being concatenated into the SQL statement.

HTTPS protects the data while it's traveling. Secure application design protects how that data is processed.

Both are necessary.

A Valid TLS Certificate Is Not a Security Audit

Another common misconception is that a website must pass a comprehensive security inspection to obtain an HTTPS certificate.

That's not how typical TLS certificates work.

For a Domain Validation (DV) certificate, a certificate authority verifies that the applicant controls the domain.

It does not guarantee that:

• The website is free from malware.
• The application has no security vulnerabilities.
• The organization operating the website is legitimate.
• The website handles personal information responsibly.

You can inspect a website's certificate using OpenSSL:

openssl s_client -connect example.com:443 -servername example.com

Or retrieve selected certificate details:

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

This can show information such as the certificate subject, issuing certificate authority, and validity dates.

But none of that constitutes a security audit of the website.

Services such as Let's Encrypt have made TLS certificates widely accessible, which is a tremendous improvement for web security.

However, that accessibility also means malicious websites can obtain valid certificates.

A valid certificate establishes technical trust in the connection, not a guarantee of the website's intentions.

What Should You Look For Instead?

HTTPS is still extremely important. You should expect modern websites, especially those handling sensitive information, to use it.

But it shouldn't be your only security check.

Here are a few practical habits:

1. Verify the domain name. Pay attention to misspellings, unusual subdomains, and lookalike domains.
2. Be cautious with unexpected links. Especially messages creating urgency around account verification, payments, or password resets.
3. Navigate directly to important websites. Use trusted bookmarks or manually enter known addresses instead of following suspicious links.
4. Enable multifactor authentication. Phishing-resistant methods, such as passkeys and hardware security keys, provide stronger protection against credential theft.
5. Keep your software updated. Browser and operating system security updates help protect against vulnerabilities that HTTPS cannot address.

These practices work alongside HTTPS rather than replacing it.

Final Thoughts

HTTPS is a fundamental part of modern web security.

It encrypts communication, protects data integrity, and helps authenticate the server you're connecting to.

But a secure connection and a trustworthy website are not the same thing.

A phishing website can have a valid TLS certificate. A legitimate HTTPS website can still contain critical vulnerabilities. And encrypted communication doesn't guarantee that your information will be handled securely once it reaches its destination.

HTTPS tells you that your connection is protected. It doesn't tell you whether you should trust what's on the other end.