Security checklist

0 of 8 items marked for your own review. This number does not measure the security of a server.

1. Verify server identity
   Why this matters

   On the first SSH connection, compare the host key fingerprint with a value from the administrator. For FTPS and HTTPS WebDAV, read the TLS certificate name and issuer before continuing. A later change in either identifier is a reason to stop, not a prompt to click through.

2. Use secure transport
   Why this matters

   Prefer SFTP, FTPS, HTTPS WebDAV, or HTTPS for S3. Plain FTP and plain HTTP WebDAV do not encrypt the password or the files. Selecting FTP in the Login dialog does not add encryption until you also choose a TLS method.

3. Protect credentials
   Why this matters

   Enter passwords, key passphrases, and secret access keys only in the application. Leave the password blank when saving a site unless you deliberately accept stored-password behavior. Do not put secrets in scripts, screenshots, tickets, or the tools on this website.

4. Review authentication methods
   Why this matters

   Use a method the server actually allows. SSH keys, agents, and Kerberos apply to SFTP and SCP. FTP and WebDAV do not use those keys. S3 uses an access key pair or credentials discovered on the PC. Turn off agent forwarding and Kerberos delegation unless you need them.

5. Understand host keys
   Why this matters

   A host key identifies the server. Your key pair identifies you. Saving the host key after you have checked it lets the next connection detect a substitution. Accepting every key, including with a script that does not pin a fingerprint, removes that detection.

6. Protect stored sessions
   Why this matters

   Saved sites remember hostnames and usernames so you do not retype them. On a shared PC, a saved password is available to anyone who can open that Windows account. Remove sites you no longer use, and prefer a private Windows login for any stored session.

7. Check file permissions
   Why this matters

   A transfer that fails with permission denied is often the right outcome. Do not make a directory writable by every user so the upload will succeed. For object storage, change the bucket policy only when you understand which principals will gain access.

8. Verify transfer destinations
   Why this matters

   Read the remote path before you upload, download, or synchronize. Website files belong in the directory the host designated, which may not be the account home. Leave preview enabled, and treat delete and mirror options as destructive until the checklist of changes looks right.

Marks stay in memory for this page view only. Reloading clears them. Nothing is stored in the browser and nothing is sent to a server.