Website security best practices: HTTPS and open paths

The rule

The United States has no single website security statute. The federal rule that reaches a company’s website is section 5 of the FTC Act, and it does not mention encryption, headers or file paths. The FTC builds the expectation case by case.

So a security case under section 5 rests on three things: injury or likely injury to consumers, that consumers could not reasonably avoid, and a balance against the benefits. Security can also be handled as deception, when a company tells consumers its security is better than it is. The GoDaddy allegations below pair a security claim with the failures alleged behind it.

Whether the FTC can use unfairness for security at all was tested in court. The FTC’s own account of the Third Circuit’s ruling in FTC v. Wyndham, of 25 August 2015, says the court “upheld” that the FTC could use the prohibition on unfair practices in section 5 to challenge the data security lapses alleged, and rejected Wyndham’s argument that it lacked notice.

What the FTC expects in practice is in its guidance. “Start with Security” tells businesses to “use strong cryptography to secure confidential material during storage and transmission”, and names Transport Layer Security (TLS) encryption as one possibility. A lesson on configuration describes companies that used SSL encryption in their mobile apps but “turned off a critical process”, which made the apps open to interception. Another lesson, on access, describes a company that stored consumer information on a server on which it had disabled the firewall. The guide does not mention security headers, and nothing the FTC published that was read for this page names them.

The orders in the cases below require a security program and independent assessments, and one proposed order carried a payment for refunds. State laws add their own security duties and differ from state to state. This page covers the federal layer. Of the state statutes, only New York’s General Business Law section 899-bb was read for it.

What PeekWell checks and how

US-15 asks two questions that a visitor’s browser can answer: is the connection encrypted and set up in the usual way, and do a few well-known sensitive paths answer from outside?

The scan is automated. The first half is the same as EU-15 and UK-15. It opens a public page the way an ordinary browser does and looks at the encryption on the connection, any part of the page that loads over plain http, and security headers such as HSTS, Content-Security-Policy and X-Frame-Options.

The second half is specific to this check. It asks whether a few things that should never be public answer from outside, such as a source-control folder, an environment file, a backup or an open folder listing. That’s all it notes. It never opens, reads or keeps what comes back, and an answer alone doesn’t say what is there or whether it matters. The report states an observation, not a conclusion.

The scan has limits, and the report says so. It reads public pages and, for the path check, whether a short list of addresses answers. It does not port-scan, try to get in where it isn’t allowed or run any security test. It does not try to get past a login, guess at other addresses, or read the content of anything. It cannot see how data is stored or who inside the company can reach it. A Passed means the expected behaviour was observed on what was scanned. It does not say the site complies.

Why it matters for a company

For the FTC, the facts in these cases are not subtle. In several of them a file or a connection was reachable by anyone.

In the 2015 settlements with two debt brokers, Cornerstone and Company and Bayview Solutions, the FTC alleged that the companies posted unencrypted documents on a website geared for debt buyers, sellers and others in the industry, “but accessible to anyone with an internet connection”. The files held names, addresses, card and bank account numbers and amounts consumers allegedly owed, for about 55,000 consumers. The settlements require a security program, with assessments by an independent party at the start and every two years.

In the GoDaddy matter, finalized on 21 May 2025 by a 3-0 vote, the FTC alleged that the company claimed award-winning security while not using multi-factor authentication, not monitoring for threats and not securing connections to consumer data. The order bars misrepresenting security, requires a comprehensive security program and calls for an independent assessor. One commissioner concurred but dissented on one count.

A third example shows how long a gap can stay open. In June 2023 the FTC alleged that Vitagene, now 1Health.io, kept nearly 2,400 health reports and the raw genetic data of at least 227 consumers in unencrypted, publicly accessible cloud storage, and that over about two years it was told at least three times. The proposed order included $75,000 for consumer refunds.

For a company the practical points are these. The FTC’s pleadings treat “reachable by anyone” as a fact that can be shown. Telling customers your security is strong makes the gap a question about the claim as well as the control. And a warning that goes unanswered, as in the Vitagene allegations, is part of the story the FTC tells.

Smaller companies and larger companies

Section 5 has no size threshold. The FTC looks at injury and what the company could have done at reasonable cost.

In a small company the gap is usually a leftover. A developer deploys the whole repository to the web root, so .git/ answers. A backup is copied next to the site before an update and forgotten. An .env file with keys sits where the site is served from. Directory listing is on by default in the host’s setup. The site is on HTTPS, but a subdomain from an old campaign still answers on plain http. The 2015 settlements were with two firms each owned by an individual, but the FTC page gives no size for either, and the allegation was a public file area.

In a larger company the problem is scale. There are many hosts, staging sites that were never taken down, agency microsites and a CDN with different rules for different paths. The GoDaddy allegations show the other pattern: security claims made at brand level, with connections and controls that did not match them across a very large estate.

How to fix it

1. Check your own paths first. From a terminal run curl -sI https://yourdomain.com/.env and the same for /.git/config, /backup.zip and any other file you can think of that should not be public. Look at the status line only. On your own site you can also look inside, and Peeky will not.
2. Keep the repository and backups out of the web root. Deploy build output only. Move dumps, archives and .env files to a folder the server does not serve.
3. Block dotfiles and version-control folders at the server. One rule in the server config is enough.
4. Turn directory listing off. Set autoindex off in nginx or Options -Indexes in Apache.
5. Treat anything that was reachable as read. If a path answered with a file that held keys or passwords, rotate them. Removing the file does not undo the time it was open.
6. Fix transport and headers. Redirect http to https everywhere, allow TLS 1.2 and 1.3, add HSTS and content security headers as described in EU-15.
7. Re-scan. Run a scan again and check the path and transport findings are gone.

location ~ /\.(?!well-known) { deny all; }
autoindex off;

This is a starting point. Whether it is enough for your data is a question for your adviser, and Peeky reports only what it sees.