Server and hosting security

• Website Security
• Updated: 4 October 2026
• About 9 min read

Four basic areas

1. 1

   Access: encrypted connection, separate passwords

   Plain FTP sends the username and password over the network unencrypted. For file transfer, use SFTP (over SSH) or FTPS (FTP encrypted with TLS); switch plain FTP off if you can. Set long passwords that are different from one another for the hosting panel, FTP, the database and the admin panel.

   : Enlarge

2. 2

   File permissions: no more than necessary

   The general recommendation is 644 for files and 755 for folders. Configuration files that contain passwords should be more restricted. Permission 777 means that everyone on the server can write to that file; a 777 granted to fix an "it doesn't work" problem is, more often than not, the start of the next security problem.

   : Enlarge

3. 3

   Only files meant to be published in the web root

   Every file in the web root can be requested by anyone who knows or guesses its address. Backups, database dumps, the .git folder, the .env file, a phpinfo page, installation scripts and copies left behind by editors should not be there.

   : Enlarge

4. 4

   Do not leak information

   If directory listing is on, the contents of folders are visible to everyone; if error display is on, file paths, queries and configuration details are printed on screen. Switch both off; let errors be written to the log.

   : Enlarge

Signs: how do you spot a misconfiguration?

• When you open a folder address in the browser, a list of files appears ("Index of /...").
• A wrong address or input shows a PHP warning on screen that includes a file path and line number.
• The web root contains files with the extensions .zip, .sql, .bak or .old, or files named backup, copy or old.
• The addresses yourdomain.com/.git/, yourdomain.com/.env or yourdomain.com/phpinfo.php return content instead of "not found". Try this on your own site.
• The file manager shows folders with 777 permissions or writable configuration files.
• Your FTP program warns of an "unencrypted connection" when it connects.
• The database management tool (e.g. phpMyAdmin) sits at a public, guessable address.

Access accounts

• SFTP or FTPS: Select the protocol explicitly in your FTP program. Do not accept certificate warnings blindly.
• Personal accounts: Open separate accounts for the agency, freelance developers and employees; close them when the work is finished. With a shared account you cannot know who did what.
• Narrow the privileges: An FTP account should see only the folder it needs.
• Two-factor authentication: Switch it on in the hosting panel and in your account with the domain registrar. If the domain account is taken over, the site and email can be redirected elsewhere.
• If you use SSH: Key-based login instead of a password, disabling direct login as root and an up-to-date system are the basic measures.
• Where you save passwords: Passwords stored as plain text in FTP programs are a target for malware that infects your computer. Use a password manager and keep your computer up to date.

File permissions and ownership

The permission digits show, in order, the rights of the file owner, the group and other users (4 read, 2 write, 1 execute).

• Files 644: The owner reads and writes, others only read.
• Folders 755: The owner writes; others can enter and read.
• Configuration files: 640 or 600 for files that contain the database password. Which one works depends on the user PHP runs as; check your hosting provider's recommendation.
• Writable folders: Only folders that genuinely need to be written to, such as uploads and cache, should be writable; disable script execution in these folders. See File upload security.

If you have SSH access, to fix permissions in bulk:

# Run in the web root: folders 755, files 644
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

# The configuration file containing the password is more restricted
chmod 640 ayarlar.php

Directory listing and sensitive files

The block below switches off directory listing and blocks access to files and folders that begin with a dot (.env, .git, .htpasswd) and to common backup extensions.

# Switch off directory listing
Options -Indexes

# Files that begin with a dot (.env, .htpasswd, .user.ini ...)
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

# Folders that begin with a dot (.git, .svn ...); except .well-known
RedirectMatch 404 "/\.(?!well-known/)"

# Backups, dumps and editor copies
<FilesMatch "(?i)(\.(sql|bak|old|orig|save|swp|log|ini|sh|dist)|~)$">
    Require all denied
</FilesMatch>

These rules are a second layer; the real solution is never to have these files in the web root at all:

• Backups: Store them outside the web root and, if possible, off the server as well.
• The .git folder: It contains the entire source code and its history. Transfer only the files to be published to the live site.
• .env and configuration files: If possible, keep them in the folder one level above the web root.
• phpinfo pages and installation scripts: Delete them when you have finished.
• Editor copies: Files such as config.php.bak, config.php~ and config.php.save do not run as PHP; they can be downloaded as plain text and the passwords inside them read.
• Database management tools: Do not leave them permanently open; if they are needed, protect them with an IP restriction and an extra password.

PHP settings

In a live environment, errors should not be printed on screen; they should be written to the log. The settings are made through php.ini, through .user.ini in the web root on hosting that uses FPM, or through the PHP options in the hosting panel.

; Live environment
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /home/kullanici/logs/php-hata.log
expose_php = Off
allow_url_include = Off
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
session.use_strict_mode = 1

• The error log should be outside the web root or closed to outside access.
• allow_url_include should stay off.
• Disabling PHP extensions you do not use and dangerous functions is an extra layer; do it knowing what your application needs.

To move the configuration file outside the web root:

<?php
// public_html/index.php  ->  the settings are one folder up, not reachable from the web
$ayarlar = require dirname(__DIR__) . '/gizli/ayarlar.php';

$pdo = new PDO(
    'mysql:host=localhost;dbname=' . $ayarlar['db_ad'] . ';charset=utf8mb4',
    $ayarlar['db_kullanici'],
    $ayarlar['db_parola'],
    [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_EMULATE_PREPARES => false]
);

Database access

• Closed to the outside: The database server should accept local connections only (localhost). If remote access is needed, open it only to specific IP addresses and, if possible, through an encrypted tunnel.
• A separate user per site: Each site should use its own database and its own user, so that when one is compromised the others are not affected.
• Least privilege: Give the application user only the privileges it needs. See the SQL injection guide.
• Password: The database password should not be used anywhere else and should not be written into the source code repository.

Other sites in the same account

If there is more than one site in the same hosting account, they can usually reach each other's files. When the weakest site is compromised, the others are affected too. Forgotten trial sites, old campaign pages and unused subdomains are the most common entry points.

• Remove unused sites and subdomains.
• Host important sites in separate accounts.
• When one site is being cleaned, all the sites in the same account should be examined together.

Questions to ask when choosing a hosting service

Part of server security is in your provider's hands, not yours. When buying a service or assessing your current one, find out the answers to these questions:

• Are accounts isolated from one another? If another customer's site on the same server is compromised, can your files be reached?
• Which PHP versions are offered; when are versions that have reached end of support removed?
• Is there SFTP or FTPS and SSH access? Can plain FTP be switched off?
• Does the panel have two-factor authentication?
• How often are backups taken, how many days are they kept, and can you restore them yourself?
• Is a free SSL certificate (e.g. Let's Encrypt) installed and renewed automatically?
• Can you get at the access and error logs; how many days are they kept?
• Are DDoS protection and a web application firewall offered?
• When there is a security incident, through which channel and at what hours can the support team be reached?

Price should not be the only criterion; isolation, backups and support are what make the difference when an incident happens.

Checklist

• File transfer is over SFTP or FTPS; plain FTP is not used.
• The panel, FTP, database and administrator passwords are all different; two-factor authentication is on in the panel.
• Everyone uses their own account; old accounts have been closed.
• Files 644, folders 755; nothing has 777 permissions; configuration files are restricted.
• Directory listing is off.
• There are no backups, dumps, .git, .env, phpinfo, installation scripts or editor copies in the web root.
• display_errors is off, log_errors is on; the log cannot be reached from outside.
• The database is closed to outside access; each site connects with a separate user.
• Unused sites and subdomains have been removed.

Frequently asked questions

Related guides

• File upload security and web shellsSecure upload rules, disabling execution in the upload folder, signs of a web shell and what to do if you find one.
• Security headers and HTTPSHSTS, CSP, X-Content-Type-Options, Referrer-Policy and Permissions-Policy, with an .htaccess example.
• Software updates and plugin securityKeeping the CMS, plugins, themes and libraries up to date; removing what is unused; supply chain risk.
• Website backup and monitoringFile and database backups, restore drills, file integrity, logs and uptime monitoring.