Article
Website Security Best Practices
Most business sites are not banks. They still leak data through forms, outdated plugins, reused passwords and API keys in JavaScript. Security here is hygiene: transport, updates, access, backups and a few headers — not a badge in the footer.
WEBCETRA Editorial · · · 11 min read
This is a practical list for owners and the developers they hire. It is not a penetration-test report and not a claim that any site is unbreakable. WEBCETRA applies these habits on services/web development work; you should ask any vendor the same questions.
Contents
- HTTPS, hosts and cookies
- Updates, plugins and abandoned themes
- Access control and accounts you actually own
- Forms, uploads and spam
- Secrets and third-party scripts
- Backups, restore tests and incident basics
- Headers and a CSP you can live with
- What a brochure site actually needs
HTTPS, hosts and cookies
Serve HTTPS everywhere. Redirect HTTP. Once HTTPS is stable, HSTS is appropriate. Mixed content (HTTP images on HTTPS pages) still causes warnings.
If you have sessions, mark cookies Secure and HttpOnly where they do not need to be read by JavaScript. Do not invent a login if a form-to-email flow was enough — extra auth is extra surface.
Updates, plugins and abandoned themes
The attack surface of a page-builder stack is a maintenance problem. Update CMS, plugins, themes and server packages. Delete what you do not use. Abandoned plugins with no owner are a standing invitation.
WordPress is fine when someone owns updates. It is a liability when “set and forget” was the launch plan. See blog/website development vs website builder for why canvas stacks age badly.
Access control and accounts you actually own
Unique logins, least privilege, and 2FA on hosting, DNS, CMS and email. Shared “admin / admin123” passwords are still how sites get taken over. Offboard people the week they leave.
Domains, DNS and hosting should sit in accounts in the company’s name. If the freelancer holds the domain, you do not have a vendor — you have a hostage situation. Procurement notes: blog/how to choose a web development company.
Forms, uploads and spam
Validate on the server. Escape output. Rate-limit public forms. File uploads need type checks and a place that is not executable as code. A contact form that emails you is still an open relay for spam if you skip basics.
Do not store card numbers. Use a payment provider. PCI is their job if you never see the PAN.
Secrets and third-party scripts
Never put private API keys in the frontend. Analytics measurement IDs are public by nature; payment secrets are not. Use environment variables on the server.
Every third-party script can see what the user sees. Tag managers stuffed with unknown pixels are a data-leakage problem as well as a speed problem — blog/how to improve website speed.
Backups, restore tests and incident basics
Backups that have never been restored are a hope. Test a restore. Keep a copy off the production server. Know who you call if the site is defaced: host, developer, and how to put up a holding page.
Logs help after the fact. If you have no logs, you will only know you were hacked when Google flags the site — a technical SEO and trust problem as well as a security one. See blog/technical seo checklist.
Headers and a CSP you can live with
X-Content-Type-Options, a sensible Referrer-Policy, frame controls, and a Content-Security-Policy you can actually run are worth more than a scanner screenshot. Perfect CSP is hard on a marketing site with embeds; useful CSP is still worth it.
Security scanners that sell fear are optional. Dependency updates and least-privilege hosting are not.
What a brochure site actually needs
You probably do not need a theatrical red-team engagement for a five-page service site. You do need HTTPS, updates, form hardening, backups and accounts you control. Applications and stores need more: blog/what is api integration and payment-provider checklists.
OWASP’s Top Ten (https://owasp.orgwww project top ten) is a useful vocabulary for developers. You do not need to memorise it to ask whether inputs are validated and secrets are server-side.
Questions
Do we need a pentest for a brochure site?
A full pentest is often overkill. Dependency updates, form hardening and least-privilege hosting are not. Applications that hold personal data deserve a harder look.
Will a security plugin make us safe?
It can add rate limits and malware scans. It cannot replace updates, unique passwords or a vendor who patches. Treat it as a helper.
What should we do after a hack?
Take the site offline if you must, restore from a known-good backup, rotate every password and key, and find how they got in before you republish. Then patch that hole. Search Console has a path for hacked sites in Google’s documentation.
Author
WEBCETRA Editorial. Practical articles from WEBCETRA on websites, SEO and digital systems. Written for business readers, not for ranking tricks.
Further reading on Google Search Central (developers.google.com/search/docs), Core Web Vitals on web.dev, and accessibility on the WCAG 2.2 quick reference.