# Security and privacy

> Source: https://www.allsweb.com/sixpreflight/docs/security-and-privacy
> Markdown for agents: https://www.allsweb.com/sixpreflight/docs/security-and-privacy.md
> Publisher: AllsWeb (www.allsweb.com)

Part of: SixPreflight documentation

SixPreflight reports the internal details of your server — its file paths, its user accounts, whether your database credentials leak. That makes the tool itself worth protecting, so it is built with several layers of its own, beyond just the sign-in password.

## The password gate

There is nothing to configure before the first screen — the folder ships with no password set, and the first time you load the page it asks you to choose one. Until that happens, the setup screen is open to anyone who reaches the URL, so set it the moment the folder is uploaded.

While no password is set, the tool does nothing else. It reports server internals and runs real load against your database, so every other screen sits behind this one gate.

**Sign-in throttling.** Five wrong attempts locks sign-in for five minutes, counted in a file rather than in the session — so clearing cookies or opening a private browser window does not reset the counter.

## Saved scans cannot be read over the web

Every saved scan describes your server's weaknesses in real detail — which credentials failed, which ports are open, what the database looks like. Each saved file is named so that, if fetched directly over HTTP, the web server executes it as PHP, the first line stops execution immediately, and the response comes back empty. That holds on nginx as well as Apache, which matters because nginx ignores the `.htaccess` rule that would otherwise be the obvious way to protect it.

## What the shipped `.htaccess` does, and its real limit

The shipped rule file denies the config file and everything under the internal library folder, turns off directory listing, and asks search engines not to index the page. On **nginx, which ignores `.htaccess` entirely**, none of that applies automatically — add the equivalent rules yourself, or rely on the password and delete the folder once you are done with it.

## Restricting by IP address (optional)

An allow-list in the config file, checked before anything else — including the very first setup screen:

```php
'allow_ips' => ['203.0.113.4', '198.51.100.0/24'],
```

:::warning Behind Cloudflare or a load balancer, this locks you out
The address SixPreflight sees is the proxy's address, not yours, so a list holding your own IP matches nothing. Adding the proxy's address instead lets in everyone behind it — on Cloudflare, that means the whole internet. Leave `allow_ips` empty and rely on the password, or restrict at the proxy itself. If you are already locked out, the resulting page prints the address that actually arrived, so you can see what went wrong.
:::

## The session cookie is scoped narrowly on purpose

SixPreflight's session cookie is scoped to the folder it is served from, not to your whole site. If it were scoped site-wide, on a server running SixPanel it would be sent to the panel and the shop as well — and it would let two separate copies of the tool on one domain sign each other out at random.

## What a confined PHP hides, and why that is not a fault

Managed hosting panels commonly confine PHP to the site's own folder with a setting called `open_basedir`. That is correct security practice and worth keeping.

It means a handful of checks — memory, processor details, swap, some web-server settings — genuinely cannot be read. Those rows say "not readable from here" rather than failing, and one row in the PHP section explains why once and gives you both ways around it.

They are not a warning about your server. They are the honest absence of an answer, and they are excluded from the score entirely rather than counted against you.

One place where that goes wrong is documented rather than hidden: on a server whose PHP runs inside a kernel sandbox, one web-server timeout is reported as unset when the web server has in fact set it. See [Limitations](https://www.allsweb.com/sixpreflight/docs/limitations#where-being-hardened-produces-a-wrong-answer-not-a-blank-one) for that one and for the full list.

## `tests/smoke.php` must never be reachable over the web

The package ships a command-line test harness that runs the entire scan in one go.

Left reachable over HTTP with no password — which is how an earlier copy shipped — a single anonymous request could trigger a full probe of the application database, several requests the server made to its own public URL, and outbound calls to Google Maps, your SMTP host and Firebase. Repeatable as often as anyone liked.

It now refuses to run outside the command line entirely. The scan itself also checks for exactly this file on your server, because a folder like this one gets copied between machines for years without anyone remembering it is there.

## What it never does

:::checks
- Never writes to an application table
- Never changes a setting — every finding is something you apply yourself
- Never sends an email or SMS to a real person
- Makes only GET requests during the exposure tests — it never posts
:::

## Removing it when you are done

Delete the folder once your server is chosen and tuned. It is password-protected and can be IP-restricted, but it reports server internals, and it has no reason to live on a production site indefinitely.

```bash
rm -rf /path/to/your/site/public/preflight
```

That removes the saved scan history along with it. If you want to keep a record, export the runs you care about as plain text first — see [Verify and history](https://www.allsweb.com/sixpreflight/docs/verify-and-history).