Most business owners assume hackers go after banks and big brands, not a dental clinic in Jeddah or a training centre in Alexandria. That assumption is exactly what makes small sites easy targets.
The attacks that hit ordinary businesses are rarely personal. They're automated programs that scan thousands of sites a day, looking for an old version, a weak password or a form that trusts whatever is typed into it. They don't care who you are. They care whether your door is open.
The good news: a handful of basics, done consistently, closes most of those doors.
Who actually attacks a small business website?
Picture someone walking down a street at night, trying every door handle. They don't know who lives in each house. They just keep walking until one opens. That's how most website attacks work, except the street has millions of doors and the walker is a program that never sleeps.
When a bot gets in, it usually wants one of these:
- Your server's power: to send spam, host scam pages or mine cryptocurrency on your bill.
- Your data: customer names, phone numbers, emails, orders, student records.
- Your traffic: redirecting your visitors to gambling or fake-prize sites.
- Your reputation: Google and browsers may flag your site as dangerous, and email providers start sending your messages to spam.
The last one often costs the most: a clean-up takes days, rebuilding trust takes months.
HTTPS and SSL: what the padlock does, and doesn't
An SSL certificate (technically TLS today) turns your site's traffic from a postcard into a sealed envelope. Without it, anyone on the same café Wi-Fi or along the network path could read or alter what's sent, including passwords and form entries. With it, the connection is encrypted, and the browser confirms it's really talking to your domain.
What it doesn't do: prove your business is honest, or that the site itself is free of holes. Scam sites have padlocks too. HTTPS protects the road, not the house.
Three current facts worth knowing:
- Basic certificates are free and can renew automatically. There's no good reason for a business site to run without one.
- Certificate lifetimes are shrinking. Since March 2026 the maximum is 200 days, dropping to 100 days in 2027 and 47 days in 2029, so automatic renewal is no longer optional.
- From Chrome 154 (October 2026), Chrome warns users and asks before opening public sites that don't support HTTPS.
The security basics every business site needs
None of this is exotic. It's locks, keys and a safe, in digital form.
| Layer | What it means | Everyday picture |
|---|---|---|
| Updates | Server software, PHP version, libraries and any add-ons kept current | Fixing the broken lock the whole street knows about |
| Strong logins | Unique passwords, two-factor authentication, limited login attempts | A key that can't be copied, plus a guard who notices someone trying 500 keys |
| Separate accounts | Each person has their own login with only the access they need | Staff get a key to their room, not the master key |
| Input checks | Every form and URL treats typed text as data, never as a command | A receptionist who files a note instead of obeying what it says |
| Backups | Automatic, stored off the server, and tested by actually restoring | A copy of the keys and documents in a different building |
| Monitoring | Alerts for downtime, unusual logins and changed files | A camera and an alarm, not just a lock |
Two attacks worth understanding
SQL injection happens when a form passes what the visitor types straight to the database. Instead of a name, an attacker types a database instruction, and a careless site runs it. The fix is well known: prepared statements, which keep data and commands strictly separate.
Cross-site scripting (XSS) happens when a site shows something a visitor typed, like a comment or a name, without cleaning it. The attacker's text becomes code running in other visitors' browsers. The fix: escape everything before displaying it.
A developer should be able to explain how your site handles both, in plain words.
Passwords are stored, not kept
A well-built site never stores passwords as readable text. It stores a one-way fingerprint (a hash), using a slow, modern algorithm; in PHP, that's the built-in password_hash function. If the database ever leaks, attackers get fingerprints, not passwords.
Custom code vs ready-made templates: an honest look
Ready-made templates and plugin-based systems are popular, which makes them well studied by attackers. When a flaw is found in a widely used plugin, bots start scanning for it within days. If nobody updates your site, it stays exposed.
Hand-written code has a smaller, less predictable surface: fewer add-ons from unknown authors and no public list of known flaws to scan for. But it is only as secure as the person who wrote it. A custom site with sloppy form handling is worse than a well-maintained template.
The honest answer: good practices and regular maintenance matter more than the approach. We compare both in more depth in hand-coded site vs ready-made template.
Payments and personal data
Don't store card numbers. Use a payment gateway so card details go directly to the provider and your site only receives a confirmation. That shrinks both your risk and your compliance burden. See accepting online payments in Egypt.
Collect only what you need. Every extra field you store is something that can leak. A clinic booking form rarely needs a national ID number.
Know the law applies to you. Egypt's Personal Data Protection Law (No. 151 of 2020) received its executive regulations in late 2025, with a one-year grace period that ends in late 2026, so compliance is now expected. Saudi Arabia and the UAE have their own data protection laws. If you handle customer data, ask a lawyer what applies to your business.
Common security mistakes
"We're too small to be a target." Bots don't check your revenue before scanning you.
One shared admin password. You can't tell who did what, and you can't remove one person without changing it for everyone.
Forgotten access. Former employees, old freelancers and past agencies should lose access the day they leave.
Backups on the same server. If the server is compromised or fails, the backup goes with it.
"It works, so don't touch it." Skipping updates is the single most common way sites get broken into.
If your site gets hacked
- Don't delete everything in a panic. You may need the evidence to find how they got in.
- Put the site in maintenance mode so visitors aren't harmed.
- Change every password: hosting, domain, email, database and site admin.
- Restore from a clean backup taken before the attack.
- Find and fix the hole, or it will happen again next week.
- Check for new admin users and unfamiliar files.
- If personal data was exposed, get legal advice on notifying customers and regulators.
- If Google flagged your site, request a review in Search Console once it's clean.
Your security checklist
- HTTPS on every page, with automatic certificate renewal
- Server software, PHP and every library or add-on up to date
- Two-factor authentication on hosting, domain, email and site admin
- Every person has their own account, with the minimum access needed
- Former staff and suppliers removed
- Automatic backups stored off the server, with a tested restore
- Forms protected against injection and spam
- No card numbers stored on your site
- Uptime and login alerts going to someone who reads them
Questions people ask
Is an SSL certificate enough to make my site secure?
No. It protects data in transit between visitor and server. It does nothing about outdated software, weak passwords or badly written forms.
Do I need a paid certificate instead of a free one?
For most business sites, no. Free and paid certificates provide the same encryption. Paid ones add organisation checks and support.
Can a custom-coded website be hacked?
Yes. Any site can be. Custom code avoids some common mass attacks, but its security depends on how carefully it's written and maintained.
How often should my site be backed up?
It depends on how often your data changes. A brochure site might need weekly backups; a store or learning platform with daily activity needs daily ones, kept for several weeks.
Who is responsible for security: the host, the developer or me?
All three share it. The host secures the server, the developer secures the code, and you control who gets access. Put that split in writing.
Security is a habit, not a feature
No website is unbreakable. The goal is to be a much harder target than the site next door, and to recover fast when something goes wrong. That comes from routine: updates, access reviews, tested backups.
That's the heart of monthly website maintenance. If you'd like a second opinion on how exposed your current site is, book a meeting with us.