Website Security After Launch: Five Things First
5 min read
A lot of people treat launch day as the finish line. The design gets signed off, the link goes out, and nobody touches the site again. Attackers see it the other way round. A site that is publicly reachable and quietly unmaintained is the easiest kind of target there is. Most attacks on small business sites come from automated tools sweeping the whole internet, picking out anything misconfigured or out of date. The five things below need almost no technical knowledge from you, and together they block the large majority of that traffic.
1. Force HTTPS, not just install a certificate
SSL/TLS certificates are essentially free now, and Let's Encrypt is where most of them come from, so nearly every site has one. The problem is having one installed without forcing it. Type a URL starting with http:// and you still land on the unencrypted version.
On that version, login credentials and form submissions travel across the network in the clear. Anyone on the same cafe Wi-Fi can read them off the wire. Encryption only counts when it is compulsory.
Once the redirect is in place, the next step up is the HSTS header (Strict-Transport-Security). It tells browsers to remember that this site is HTTPS only, so even the first plaintext request never happens.
Last is the certificate itself. Click the padlock in the address bar to see when it expires, and set up automatic renewal. A certificate that lapses with nobody watching puts a security warning in front of every visitor, and most of them leave at that screen.
2. Keep updating: stale components are the most common way in
Most attacks on websites come from automated tools scanning the whole internet for out-of-date versions with published vulnerabilities. That maps directly onto A06 in the OWASP Top 10, meaning use of components with known vulnerabilities. Nothing sophisticated happens. You simply had not patched yet.
WordPress makes this especially visible. Core, theme, plugins: any one of them left behind can be the hole. Treat updating as a standing maintenance task, check your core systems and CMS at least monthly, and apply anything marked as a security release quickly.
Updating carries its own risk, most of all on sites with custom work in them. The way round it is to back up first, and to check compatibility on a staging copy before touching production if the site has been customised. Skip that step and a broken update you cannot roll back costs far more than waiting an extra week would have.
3. Admin accounts: the part that gets brute forced
Automated tools try to log in to common admin URLs every day, and on WordPress the first stops are /wp-login.php and /wp-admin. They work through dictionaries of leaked credentials one pair at a time. If a single account has a weak password, getting in is only a matter of time.
The point of admin security is not making one password enormously complex. It is making guessing a bad use of the attacker's time. Do the five things below together and the cost of guessing rises far enough that automated tools move along to the next target.
Five locks on the back door
- Do not use a default account name. admin and administrator hand over half the answer before anyone starts.
- Give every account a long, unique password. Use a password manager, and never reuse one across sites.
- Turn on two-factor authentication. If a password does leak, there is still something in the way.
- Block repeated attempts. Cap failed logins, or move the admin login to a different path and restrict it by IP.
- Close accounts when people leave. Disable the logins and access keys of departing staff and finished contractors the same day.
4. Customer data: you are probably holding more of it than you think
If your site has member registration, orders, bookings or a contact form, you are holding personal data about your customers. A leak damages your reputation, and under Taiwan's Personal Data Protection Act, the PDPA, it can also leave you with notification and compensation duties. The PDPA covers similar ground to the GDPR in principle, though the thresholds and penalties are set differently, so check which regime applies to the people whose data you actually hold.
The principle behind data protection is intuitive: do not collect what you do not need, and look after what you do. Start at collection and ask only for the fields the business genuinely uses. National ID numbers, dates of birth and similar details usually are not necessary. Data that was never stored cannot leak.
For what you do keep, encrypt it in transit and at rest. Forms go over HTTPS, sensitive database columns get hashed or encrypted, and passwords are never stored in plain text. Keep permissions minimal too. Everyone, including you, gets the least access their job needs, so day-to-day work does not happen under the top-level administrator account.
The other end of the problem is retention. Decide how long each category of data needs to be kept, and delete customer records once they are past it. Holding them brings in no extra revenue, only extra exposure.
5. Regular checks: finding the holes you cannot see
The four items above are groundwork you can handle yourself. What weaknesses your site actually exposes, though, is usually not visible to the naked eye. Old components with published flaws, permissions set too wide, a test entry point somebody forgot to close: those take tooling and experience to surface.
Running a vulnerability scan or a security health check on a schedule works the way an annual physical does. It finds the small problems before anyone exploits them rather than after. The website and the server are two different layers, and the checks differ accordingly.
| Check | What it looks at | When to repeat it |
|---|---|---|
| Web application scan | The application layer, item by item against the OWASP Top 10 | After a major redesign or a new feature goes live |
| Host scan and health check | Patch status, open ports, suspicious processes | When you change host, move data centre, or take over an existing server |
Change the environment and you change what is exposed, which is why a redesign or a host move is worth a fresh scan. When you read the report, the number of findings matters less than whether somebody has ordered them for you: what to fix now, and what can be scheduled. A report that lists problems without ranking them leaves you no clearer about what to do tomorrow.
Launch is the start of the job. Get these five things right and you have already blocked the large majority of automated attacks in circulation. What is left, the part you cannot see, is what periodic testing covers. Security is something a site carries with it for as long as it is online.
Common questions
- Does a small website really need security work after it launches?
- Any site that is publicly reachable gets scanned and probed by automated tools, whether or not anyone has heard of it. HTTPS, updates and account security are close to mandatory. Sites that collect customer data should also be tested periodically. Small sites with no IT staff are the ones picked out most often.
- I have an SSL certificate. Is my site secure now?
- Not by itself. SSL/TLS protects the connection from eavesdropping. It does nothing about a vulnerable out-of-date plugin, a weak password being brute forced, or a misconfigured admin area. The certificate is the entry requirement, not the finish line.
- Can I do all this myself, or should I hire someone?
- HTTPS, updates and account security are all within reach on your own. Working out which weaknesses your site actually exposes normally takes tooling and experience. A reasonable split is to keep the groundwork in house and bring someone in periodically for a vulnerability scan or health check to cover the blind spots.