Common website security threats
The threats that most often hurt a small site are SQL injection, cross-site scripting, password guessing, outdated plugins and traffic floods. Each fails in a different place: the database query, the page output, the login, the update habit, or the network link. An SSL certificate stops eavesdropping — it stops none of the other four.
For owners of small Indian sites: what actually breaks, which control covers which threat, and the first hour after you notice a change.
knowledge
- Read time
- 4 min
- Sections
- 5
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 15 November 2026.
How do SQL injection and cross-site scripting attack a site?
SQL injection (SQLi) copies visitor input into a database command so data can be read, changed or deleted; cross-site scripting (XSS) prints that input back as HTML or script so another visitor's browser runs it. Both are application bugs in your code or your CMS extensions — no hosting setting causes them, and no panel toggle fixes them.
| Threat | What people notice | What limits the damage |
|---|---|---|
| SQL injection | Strange database errors, missing rows, an admin account nobody created | Queries that keep input separate from the command; a database user with only the rights the site needs |
| Cross-site scripting | Unexpected script, a changed page, users signed into the wrong session | Output encoding, a tight content security policy, forms that reject raw HTML |
Do not paste proof-of-concept strings into a site you do not have permission to test. For your own site, a vulnerability check is the safe starting point, and the fix belongs in the code or the plugin, not in a WAF bandage alone.
How do bots take over logins with brute force and credential stuffing?
Brute force tries many passwords against one account — wp-admin, SSH or the hosting panel — while credential stuffing replays leaked username-password pairs from other sites, betting on reuse. Neither needs a software bug. A weak or reused password is the whole vulnerability.
- Unique passwords on the panel, the CMS and email — reuse is what turns someone else's leak into your incident.
- Multi-factor authentication wherever the product offers it; a correct password then stops being the whole login.
- Rate limiting or lockouts on repeated failures; an endless login form is an open queue for bots.
- Do not expose the panel publicly where a VPN or allow-list can cover the few people who administer it.
Lockouts slow guessing; MFA ends it. The WordPress-specific daily routine — including login protection — is the WordPress security checklist.
How do outdated plugins become malware backdoors and SEO spam?
An outdated plugin or theme can carry a known flaw that lets a stranger write files or create an admin user, and the site then grows hidden backdoors, extra admins or spam pages aimed at search engines. Updating — or removing the extension entirely — closes the flaw; if files are already changed, you restore a clean backup rather than trusting the infected copy.
- Remove unused plugins and themes: an inactive extension can still be reachable.
- Update on a schedule: CMS, plugins and theme together, and read what changed when an update is large.
- Watch for new admin users, unfamiliar files and pages full of unrelated keywords.
- Keep a pre-change backup and test that you can restore it.
What scanning does and does not catch is explained in what malware scanning is, and the browser-side warning buyers see is covered in "the site ahead contains malware". If files are encrypted or replaced and the business cannot publish, read what ransomware does to a website before paying anyone who wrote to you from the site.
How do DDoS floods take a web server offline?
A volumetric flood fills the network link so real visitors get no reply; an application-layer (Layer-7) flood looks like ordinary browsing and exhausts PHP workers, database connections or disk instead. The site times out either way, and the difference matters because the defences live in different places.
| Kind of flood | What runs out | What a small server cannot do alone |
|---|---|---|
| Volumetric | The network link | Absorb more traffic than the port can carry |
| Application layer | PHP workers, database connections, disk | Let every expensive URL do unlimited work |
A certificate and a host firewall add no bandwidth, and a security plugin cannot filter traffic that never reaches the server. Where upstream filtering fits is explained in what DDoS protection does. This page does not describe how to generate either kind of flood.
Which control covers which threat?
Each control covers exactly one failure: isolation stops one account reading another's files, a WAF blocks known-bad request patterns, backups restore a clean copy, and SSL keeps passwords off the wire in clear text. None of the four fixes a database command built from raw input — that fix belongs to the code.
| Control | Helps with | Does not replace |
|---|---|---|
| Account isolation | A neighbour site reading your files | A bug inside your own code |
| WAF rules | Some injection and script patterns at the HTTP layer | A proper fix in the query or the template |
| Daily backups | Returning to a copy from before a defacement | Finding how the change got in |
| SSL certificate | Hiding the password and session on the wire | A flood, a leaked password or a bad query |
What a certificate does and does not secure is spelled out in what an SSL certificate is. To have this work done on the account rather than only explained, website security services is the commercial page.
What should you do in the first hour after noticing a change?
In the first hour after noticing something wrong: change the passwords, snapshot the account without "fixing" anything, check for admin accounts you did not create, then restore from the newest clean backup. Deleting the odd-looking file first destroys the evidence that explains how the site was entered.
- Change passwords for the CMS admin, the hosting panel and the database user.
- Snapshot files and database as they are, before any cleanup.
- List admin users and recent file changes — look for accounts and files you cannot explain.
- Restore the newest clean backup, then update everything before reopening.
- Report it — email support@webji.services with the URL and the time you first saw the change; the desk answers 24/7 in Hindi and English.
Frequently asked questions
Does an SSL certificate make my website secure?
No. SSL encrypts the connection between the visitor and the server, which stops eavesdropping and password sniffing on the wire. It stops no injection, no brute force, no outdated plugin and no flood. A padlock says the line is private, not that the code at either end is safe.
Which threat hits WordPress sites most often?
Exploitation of outdated plugins and themes, followed by password guessing on wp-admin. The two habits that prevent most incidents are updating on a schedule and removing extensions the site does not use. Both take minutes; the cleanup after skipping them does not.
What exactly is credential stuffing?
Bots replaying username-password pairs leaked from other websites, betting that people reuse passwords. The attack needs no bug in your site — only a user who used the same password elsewhere. Unique passwords and multi-factor authentication defeat it.
Can a small Indian site actually be DDoSed?
Yes. Floods do not check the size of the target — a small shop's link saturates faster than a large one's. Volumetric floods have to be filtered upstream of your server, which is why a plugin cannot solve them.
I found files I never uploaded. What is the first move?
Do not delete them yet. Change the passwords, snapshot the account as it stands, list recent file changes and unknown admin users, then restore from the newest clean backup and update everything. Deleting first destroys the evidence of how the site was entered and usually leaves the entry point open.
Last editorial update: 15 November 2026.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.