AI-era website security for small sites

Most website security advice has not changed in ten years, and most of it is still right. Use a password manager. Turn on two-factor authentication. Keep WordPress and its plugins updated. Have backups you have actually restored once. All of that still holds, and website security best practices every site owner needs is the piece to read for that foundation.

This is the new part.

Four ways AI changed the threat picture

AI changes website security in four ways: code an AI wrote with secrets or missing checks, AI crawlers and scrapers as load, AI features on the site that can be manipulated, and AI-made phishing aimed at the account holder.

Three of those four are not attacks on your server. They are new ways for an ordinary mistake to reach the internet, and the one that genuinely targets you goes after your inbox rather than your website.

No host can honestly tell you a site is completely safe. What we can tell you is which of the four your hosting covers, which few minutes of checking cover most of the rest, and what our own emails look like so you can recognise the fake ones.

Risk one: the code an AI wrote

The most likely way AI hurts a small website in 2026 is writing something helpful with a key sitting in it.

This is measurable rather than speculative. Veracode's GenAI Code Security Report, published 30 July 2025, tested over 100 large language models across Java, Python, C# and JavaScript and found that 45% of code samples introduced a vulnerability from the OWASP Top 10, with cross-site scripting defences failing in 86% of relevant samples and failure rates ranging from 38% in Python to 72% in Java. The least comfortable finding: newer models did not do better on security even as they got better at producing code that works.

Working and safe are different tests, and an assistant optimises for the first because that is what you asked for. A key sitting in a JavaScript file is invisible until someone reads your page source, which takes about four seconds.

Two problems account for most of it, and both are checkable by a non-programmer.

Secrets in files that ship to the browser. An AI asked to "make my contact form email me" or "connect this to Stripe" has to put credentials somewhere, and the path of least resistance is the file it is already writing. If that file is JavaScript the browser downloads, the key is public. Search the files you were given for key, secret, token, password and sk_. Anything that looks like a long random string next to one of those moves server-side before the site goes up, and running AI-powered apps and features on ordinary hosting covers environment variables for PHP, Node and Python on a shared plan. A five-minute version of this check is coming , as is a playbook for the day you find out a key was already live .

Pages that do not check who is asking. The second common finding is a missing authorisation check: an admin page, a delete action or a "show my orders" endpoint that does the work for anyone who knows the URL. AI-generated code builds the happy path well and skips the gate, because the gate was not in the prompt. The test needs no code reading. Open a private browsing window, visit the admin or account URL without logging in. If you get the page instead of a login screen, it is not ready.

Then test it somewhere that is not your live site. A staging copy or throwaway subdomain costs nothing on a shared plan and turns a bad afternoon into a shrug. A launch checklist for a whole vibe-coded app is its own piece .

Risk two: bots and scrapers reading your pages

The second change shows up on your bill and in your load times, not in a security report. AI crawlers read the public web at a volume built for training datasets, not for browsing. Search Engine Journal reported, on 26 March 2025, Vercel data showing GPTBot generating 569 million requests in a single month and ClaudeBot 370 million, together about 20% of Google's search crawler volume, plus the Read the Docs project cutting daily traffic from 800 GB to 200 GB by blocking AI crawlers and saving roughly $1,500 a month in bandwidth. Those are documentation sites with enormous page counts, so do not read your own numbers into them. The pattern transfers: a crawler that ignores a crawl delay can cost you more than your visitors do.

For a small site this is a cost and performance question, not a breach. Nothing is being stolen that was not already public. What you feel is CPU, entry processes and response time, and on shared hosting those decide whether your site is quick at 9am.

The decision is not purely a security one. Some of these crawlers feed the assistants that now recommend businesses to people, so blocking everything with a bot in its name is how a small business becomes invisible where people ask for recommendations. Let through the crawlers that send you traffic or citations, and act only on the ones costing you money without giving anything back.

Working out which is which starts in your logs. In cPanel, Metrics then Raw Access gives you every request that hit your site: IP, timestamp, path, status code and user agent. Reading access and error logs explains the format line by line. The pattern you want is a wall of requests to the same paths in the same second from one user agent. A person does not do that.

Once you have a name you have two levers. The polite one is robots.txt, which the well-behaved crawlers honour. The firm one is a rewrite rule, and blocking bots by user agent in cPanel gives you the exact .htaccess block, the [OR] chaining for several bots at once, and the curl -A command to confirm the 403 fires. It is honest about the limit too: a user agent is just text the client sends, so anything genuinely malicious will lie about it. This stops the aggressive-but-honest crawler and does nothing to a scraper that wants to hide. For that you block by IP range from Security then IP Blocker, or open a ticket. A piece on reading your logs for AI scrapers and blocking them on cPanel is coming separately .

Risk three: the AI features on your own site

The third change did not exist as a category for small sites two years ago. If you have added a chatbot, an AI search box, a review summariser or a support widget, you have put something on your site that reads text and then acts on it.

Prompt injection is the first entry on the OWASP Top 10 for LLM Applications, and it stays there because it is a design property rather than a bug to patch. A language model reads instructions and content through the same channel, so it cannot reliably tell what you told it to do from what it later reads in a page, a form field or an uploaded file. Anyone who can get text in front of your widget can try to give it instructions.

The realistic failure on a small site is not dramatic. It is a chatbot talked into promising a refund policy you do not offer, quoting a price you never set, or repeating its own instructions back, including anything you pasted in about internal processes. If the widget can read order data or write to your site, it gets worse quickly.

Three settings cover most of it, all in the widget's own configuration rather than anywhere technical.

What it can read. Point it at content you wrote and published, not at your customer database. A chatbot answering from your own pages cannot leak what it was never given.

What it can do on its own. Most widgets offer actions: create a ticket, apply a discount, look up an order, send an email. Each one you turn on is a thing a manipulated conversation can trigger. Prefer the ones that create a request for a person over the ones that complete a transaction.

Whether its output goes live unread. AI-written product descriptions and review summaries that publish automatically are the quiet version of this risk, because injected text ends up on your page where visitors and Google both read it. A review queue is boring and it works.

If the widget is a WordPress plugin, the plugin-level version sits in AI and WordPress: plugins, themes, agents and your hosting. The plain-language prompt injection explainer and the firewall rules for a chatbot widget on shared hosting both go deeper than a pillar can.

One point worth separating, because people conflate the two. A chatbot on your website and an AI assistant connected to your hosting account have different risk profiles. The chatbot talks to strangers and should be able to do almost nothing. The assistant talks only to you, and on Flashcloud every change it proposes waits for your approval. AI agents and your hosting account covers that model in full. Whether an agent should hold write access to your site is its own argument .

Risk four: the phishing aimed at you

The fourth change is the one most likely to cost a small business money this year, and it does not touch your website at all. It goes after the person who holds the account.

AI made convincing phishing cheap. The grammar is correct now, the branding is right, the page it links to is a decent copy, and the email knows your domain name and expiry date because that data is public in WHOIS and RDAP records. Malwarebytes documented one campaign in June 2026 that showed victims their real domain name, real registrar and real expiry date on a fake renewal page, then ran a fifteen-minute countdown and a two-euro offer to rush the payment. The lookup looked like a registry query and was generating the data locally. The giveaway was a Gmail address on the billing notice.

The renewal notice works best because it combines real data, a real deadline and a payment you were expecting. Some are not even after your card: they are unauthorised transfer attempts dressed as renewals, where paying the invoice authorises moving your domain to another registrar.

So here is the part only your host can give you.

A genuine Flashcloud renewal notice names the exact domain and its actual expiry date, which you can confirm in the portal. It links to your own portal account. It does not demand action within hours. It never asks you to paste a transfer authorisation code to complete a renewal, because a transfer code is only needed when you are deliberately moving a domain to a new registrar.

And what it never contains:

• A third-party payment page. Flashcloud renewals are paid in the portal, by you. If a link goes anywhere that is not portal.flashcloud.com, it is not us.
• A request for your password, your card details or a two-factor code. We never ask for any of those by email.
• A countdown, a final notice banner, or a price you have not seen on your own invoices before.

The rule that makes this easy to apply at eight in the morning: never pay from an email link. Open a new tab, type portal.flashcloud.com, and look at the domain's real expiry date and auto-renew status. If auto-renew is on, there was nothing urgent to begin with. Domain renewal notices: scam or legit? is the full checklist, including the registrar lock that blocks the transfer version outright.

If you already clicked and entered details, open a ticket from the portal, because a suspicious transfer attempt is much easier to stop early. Turn on two-factor authentication while you are there. There is a longer piece on hardening a hosting login coming , and a dated version of the renewal-email question .

The safety net: backups, firewall, scanning, people

This part runs whether or not you read any of the above. All Flashcloud shared plans run on NVMe storage, LiteSpeed web servers, Cloudflare CDN and cPanel, with a web application firewall (Imunify360), daily malware scanning and DDoS protection included. None of it is an add-on tier and none of it needs configuring.

Daily backups with 30-day retention. Flashcloud keeps daily backups with 30-day retention and one-click restore on every plan, stored on separate infrastructure from your live data, covering files, databases, email and DNS. You restore from the portal under Services, your hosting, then the Backups tile, choosing the scope: everything, files only, a single database, or email. Files only is the one that matters here, because it is how you undo a bad upload or recover what an AI-written script deleted. Our backup options covers the mechanics including the Generate backup button for an on-demand copy before a risky change.

Two honest limits. The most recent backup can be up to 24 hours old, so the worst case is losing a day, not nothing. And our backups live inside the Flashcloud environment, which answers "I broke my site" but not "what if Flashcloud disappears". For a business-critical site, take a copy elsewhere through cPanel's Backup Wizard or a plugin pushing to your own cloud storage. A backup you have never restored is a hope rather than a plan, the argument in how to test your website backups before you need them. Backups as the last line when AI breaks something is coming separately .

The web application firewall. Imunify360 sits in front of your web server and inspects every request against known attack signatures: SQL injection, cross-site scripting payloads, path traversal, malicious uploads. A match gets a 403 and never reaches your code. That matters more than usual for AI-written code, because the firewall checks the request whether or not your application remembered to.

It also means you will occasionally see a 403 on something legitimate, usually a form or page builder sending an unusual POST. The fix is a scoped exception, not a bypass: find which rule fired, then ask support to whitelist that rule ID for that path. What is a WAF? Imunify360 on Flashcloud explained covers diagnosing the rule and getting a narrow exception written. Turning the firewall off to get past one form removes protection from every other page on the account.

Malware scanning, and cleaning. Scanning runs daily on every plan, and we clean anything we find during a migration at no charge. If you suspect something between scans, support can run a check and walk the clean-up with you rather than handing you a report.

People. Flashcloud support is answered by people, not by an AI chatbot first. That is a security feature more than a convenience, because all four risks produce the same moment: you are looking at something you do not understand and need someone to say whether it matters.

A ten-minute monthly check

Not a framework. Eight things, in the order that catches the most for the least effort. Put it in your calendar on the first of the month, next to your day-to-day site routine, and stop thinking about security in between.

1. Updates, two minutes. WordPress core, plugins, themes. Staging first if the site earns money.
2. Anything new that AI wrote, two minutes. Search this month's new files for key, secret, token and password. Open a private window and hit any admin or account URL logged out. If either turns up something, fix it first.
3. One backup restore, two minutes, quarterly rather than monthly. Restore files only to a staging subdomain and load the homepage. The step everyone skips, and the only one that proves the net is there.
4. Logs, one minute. cPanel, Metrics, Raw Access. You are looking for one user agent appearing hundreds of times, and repeated hits on wp-login.php or xmlrpc.php from many IPs.
5. Your chatbot's settings, one minute. Still pointed only at content you published, still unable to complete transactions on its own, still not publishing anything unread.
6. Connected AI assistants, thirty seconds. The AI Agents page in the portal lists what is connected, with permissions and a last-used date. Anything connected for one job months ago gets disconnected.
7. Two-factor, thirty seconds. On, on the portal and on wp-admin.
8. Renewal dates, thirty seconds. Check your real expiry dates once a month and you will never need to believe an email about them again.

What is deliberately not on this list: everything your hosting already does. You are not checking the firewall or confirming last night's backup ran. That is the deal.

The four AI risks need less new behaviour than the headlines suggest. Read the code you did not write before you upload it. Know which bots are costing you. Keep your widget on a short leash. Never pay from an email link. The rest is the old advice, still working, with a net underneath for the day you get one of them wrong.

The net is the part you buy rather than build. A firewall, daily malware scanning, DDoS protection and 30 days of backups come with every Flashcloud web hosting plan, which is why the monthly check takes ten minutes.