Comprehensive Guide to Securing Web Applications: Best Practices Across All Stacks

Most websites that get broken into were never chosen. A script scans millions of addresses for one known weakness — an out-of-date plugin, a reused password, a database backup in a public folder — and takes whatever it finds. The good news: one short list of controls stops nearly all of it, and most of it is one afternoon's work.

This guide walks the stack in the order attackers walk it: the hosting account, the software you installed, the connection, the files on disk, the code you wrote. It is written for a business owner running WordPress on shared hosting and for a developer shipping a first PHP or Node app, and it says plainly which parts your host handles and which are yours.

1. Know what you are defending against

Almost every compromise on shared hosting arrives through one of five doors. Knowing which is open tells you where to spend the afternoon.

Notice what is not on that list: clever, targeted, zero-day attacks. They exist, but they are not what takes down a small business site. Boring maintenance is the defence.

2. Patch everything, on a schedule you keep

Most mass compromises exploit a bug fixed months earlier. The patch existed; nobody applied it.

The version selector is covered in how to change PHP versions in cPanel, and the CMS steps in the complete WordPress hardening guide.

3. Strong authentication, everywhere it matters

You have more logins than you think: client area, control panel, FTP and SSH, database, CMS admin, email. An attacker needs only the weakest one.

Use a password manager. A long random passphrase you never retype beats a clever pattern you reuse. If one password protects your email and your hosting, a leak elsewhere gives away both — password managers compare the practical options.

Turn on two-factor authentication, starting with the accounts that undo everything else: your Domain India account, your control panel, your CMS admin. See two-factor authentication setup and account security best practices.

Give every person their own login. Shared logins mean you cannot tell who did what, or revoke one person's access when they leave. In WordPress use the Contributor or Editor role, not Administrator; in your panel, create FTP accounts scoped to one folder instead of sharing the main password.

Protect the admin page. Brute-force attempts against /wp-admin never stop. Password-protecting the directory puts a second lock in front of the login.

Do not forget the domain. If someone takes over your registrar account they repoint your domain and every other control here becomes irrelevant. Keep that login on 2FA, the domain lock on and the contact email current — see domain security.

4. HTTPS on every page, not just the checkout

Plain HTTP exposes login forms, session cookies and form submissions to anyone on the network path — the café Wi-Fi, the hotel router, the ISP. Free auto-renewing certificates are included with Domain India shared hosting, so there is no reason to run without one.

While you are in .htaccess, add the cheap headers that close whole categories of attack:

# .htaccess — works on Apache, which is what Domain India shared hosting runs
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

X-Content-Type-Options stops a browser guessing that an uploaded text file is really a script; X-Frame-Options stops your pages being framed to trick users into clicking. A Content-Security-Policy is the strongest and the fiddliest to get right — see security headers explained.

5. Files, permissions and secrets

Permissions are simple and people still get them wrong. The rule: the web server must read your files, and almost never write them.

If a plugin or installer tells you to chmod 777, it is wrong: fix the ownership, or use the File Manager, which writes as your user. On DirectAdmin, see how to manage file permissions.

Turn off directory listing. A folder with no index file will show its contents; Options -Indexes in .htaccess stops it.

Keep secrets above the web root. A secret is anything that lets someone act as you: database passwords, API keys, SMTP and gateway credentials. Your home directory holds public_html, and nothing above public_html can be requested over HTTP. Put the config file there, chmod 600, and include it:

<?php
// /home/youruser/config/app.php — above public_html, chmod 600
return ['db_host' => 'localhost', 'db_name' => 'youruser_shop',
        'db_user' => 'youruser_app', 'db_pass' => 'a-long-random-string'];

// in public_html/index.php:  $config = require __DIR__ . '/../config/app.php';

Never commit secrets to Git. Add .env and your config file to .gitignore before the first commit. A secret that was ever committed lives in the history and must be rotated, not just deleted.

Give the database user only the rights it needs. An application almost never needs DROP or CREATE: in cPanel's MySQL Databases page, tick only SELECT, INSERT, UPDATE and DELETE, and keep a full-rights user for migrations. Port 3306 is firewalled, so the database is unreachable from the internet; for a desktop client, use an SSH tunnel.

Keep these out of public_html entirely: database dumps (backup.sql, dump.sql.gz), zip archives, config copies (wp-config.php.bak, config.old), the .git folder, and any script you uploaded "just to test something". If you deploy by cloning a repository into the web root, /.git/config and the objects are readable, often including credentials from your history.

Test it: open /.env, /.git/config and /backup.sql on your domain. Anything not a 403 or 404 is a five-minute fix.

Rotate everything after an incident or a staff change: database, panel, FTP, API keys, CMS admin. Changing one and leaving the rest is how sites get re-hacked a week later.

6. Never trust input: the injection classes

This section is for anyone who writes code. A handful of bug classes cause most application-level breaches, and each has one fix you apply everywhere.

SQL injection

The fix is prepared statements with bound parameters. Not escaping, not quoting, not a filter function — parameters.

<?php
// Wrong: $sql = "SELECT * FROM orders WHERE id = " . $_GET['id'];

// Right: bound parameter, and ownership checked in the same query
$stmt = $pdo->prepare('SELECT id, total FROM orders WHERE id = :id AND user_id = :uid');
$stmt->execute(['id' => $_GET['id'], 'uid' => $currentUserId]);
$order = $stmt->fetch();   // false if it is not theirs

The same two rules apply in every language — in Node with mysql2, db.execute('SELECT id, total FROM orders WHERE id = ? AND user_id = ?', [orderId, currentUserId]). Binding the parameter stops injection; checking user_id stops your customer changing ?id=1001 to 1002 and reading someone else's order. That second bug is more common than injection, and no firewall catches it: the request looks normal. More in preventing SQL injection.

Cross-site scripting

Any value from a user must be escaped for the exact place it is printed.

<?php
function e(string $s): string {
    return htmlspecialchars($s, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
echo '<p>Hello ', e($name), '</p>';   // the tag renders as text

HTML body, attribute, URL and JavaScript each need a different encoder — htmlspecialchars for the first two, rawurlencode for a URL. For rich text, use a sanitiser with an allow-list of tags; deny-lists always miss something. See preventing XSS.

Cross-site request forgery

Without a token, any page your logged-in user visits can quietly submit your forms as them — change their email, add an admin. Every form and JSON endpoint that changes data needs a random per-session token you verify on submission, or SameSite cookies plus an Origin check. Frameworks give you this; check you did not switch it off. See CSRF tokens in PHP forms.

File uploads

Decide the type by reading the bytes, not the extension or the Content-Type the browser sent. Give the file a random name and store it outside the document root — or, if it must stay web-reachable, stop the server executing anything there:

# uploads/.htaccess
<FilesMatch "\.(php|phtml|phar|cgi|pl)$">
    Require all denied
</FilesMatch>

Then test it: upload test.php, request it, and confirm you get a 403.

Passwords and errors

If your application has its own login, store passwords with password_hash() in PHP, or Argon2, bcrypt or scrypt elsewhere — never MD5, never SHA-1, never reversible — and rate-limit the login. See secure password hashing. And turn display_errors off in production: a stack trace hands over your file paths and framework version.

7. Backups you actually control, and a restore you have tested

A backup is not a backup until you have restored it. Ransomware, a bad update and a fat-fingered DELETE all have one answer.

Domain India shared hosting includes weekly backups. Treat that as a safety net for the server, not your backup strategy: a weekly snapshot may not hold this morning's order, and a compromise found three weeks late is older than the snapshot. Take a fresh copy from the panel before any change — how do I download a backup of my site — and for a scheduled off-site copy, automated backups with cron and rclone.

8. What Domain India's servers already do — and what they cannot

This is the part you do not have to build. The table below was measured on our cPanel shared server on 20 September 2026; the DirectAdmin server runs the same CloudLinux, CageFS, Imunify360 and CSF stack. None of it needs setup from you.

Two things it does not do: you cannot start a malware scan yourself from the panel, and you are not emailed when something is found. Cleanup is automatic and silent — which is why the weekly checks in section 9 matter, and why finding the entry point is still your job.

That PHP hardening is also why some software will not run here. proc_open, popen, fsockopen and dozens more are disabled for both web and command-line PHP, which blocks much of what uploaded malware does — and also stops Composer, some SMTP transports and job runners that shell out. The full list is in PHP disabled functions on shared hosting; the cPanel ModSecurity guide explains the rules if a legitimate request is blocked.

That stack is configured server-wide, one configuration for every account, so it is the same on Starter, Growth and Business. You pay for resources, not protection.

Prices are Domain India list prices on 19 September 2026, excluding 18% GST. All plans: cPanel hosting, DirectAdmin hosting.

9. Notice it early, and know what to do if it happens

Everything above is prevention. The last control is detection: what separates an incident from a disaster is how many days passed before anyone noticed.

Check these weekly:

• Google Search Console. It reports malware and hacked-content warnings before most owners notice anything. Verify your site if you have not.
• Error and raw access logs: requests to files that do not exist, .php requests inside your uploads folder, spikes from one IP.
• New files you did not create. Sort the File Manager by modified date.
• Your user list. An unexplained administrator account is the clearest sign there is.
• Your outbound mail. A bounce flood usually means your account is sending spam.
• An external change monitor. A free checker that emails you when the site goes down or the homepage changes buys days.

If it has already happened, stop reading and work the incident checklist instead. The order matters: doing it out of order re-infects the site.

And plainly: restoring a backup without finding the entry point is not a fix. The attacker walks back in through the same door within days.

Frequently asked questions

Ready to tighten things up? Three quick wins: turn on two-factor authentication, confirm your free SSL certificate is issued and forcing HTTPS, and check that /.env and /backup.sql return 404. Still choosing a host? Compare cPanel and DirectAdmin hosting — the same stack runs on both. If something on your account looks wrong, open a ticket and our team will check it from the server side.