Security
Web security: basics every website needs
Business websites need a defined security baseline: HTTPS, current software, secure forms and clear update processes.
What you actually need to protect
| Asset | Risk if exposed |
|---|---|
| User data (forms, login) | GDPR, loss of trust |
| Admin access | Defacement, extortion, data leak |
| Availability | Downtime, SEO damage, revenue loss |
| Reputation | Phishing via compromised domain |
Not every site needs a SOC. But HTTPS, patches and access control are mandatory.
HTTPS everywhere
- TLS 1.2+ (prefer 1.3) on all pages, not just login
- No mixed content (HTTP resources on HTTPS pages)
- HSTS header so browsers enforce HTTPS
- Auto-renew certificates (Let's Encrypt, hosting provider)
HTTPS is a ranking signal and trust baseline (see also SEO fundamentals).
Secure development (OWASP core)
Validate input server-side: forms, search, API parameters. Client validation is UX; server validation is security.
SQL injection: Parameterised queries / ORM, never concatenate strings.
XSS: Escape output, set Content-Security-Policy (CSP) to limit script sources.
Secrets: Never commit API keys or passwords. Environment variables or host secret manager.
Dependencies: npm audit, Dependabot, regular updates. Many breaches exploit known, unpatched flaws.
Authentication and admin
- MFA for CMS, hosting and admin accounts
- Strong passwords, no reuse
- Passwords hashed (bcrypt/Argon2), never plaintext
- Session timeout, secure cookies (
HttpOnly,Secure) - Brute-force protection (rate limiting, lockout)
Fewer exposed admin surfaces = smaller attack surface. Static sites (Next.js SSG) have fewer vectors than unmaintained WordPress.
The architectural trade-off behind this is covered in the overview of modern web technologies.
Updates and backups
Patch rhythm: CMS, plugins, Node dependencies, server images. Test staging, then production.
Backups: 3-2-1 rule, encrypted, test restore (a backup never restored is worthless).
Monitoring: Failed logins, unusual traffic, file changes. Alerts to someone who responds.
GDPR and forms
- Collect only data you need
- Keep privacy policy current
- Document consent for marketing/tracking properly
- Define processes for deletion and access requests
Contact forms via mailto: (as on bitautor.de) reduce server storage but don't replace privacy information.
Practical checklist
- HTTPS and HSTS active?
- All dependencies and CMS plugins current?
- MFA on hosting and CMS?
- CSP and security headers (
X-Frame-Options,X-Content-Type-Options) set? - Backups + last restore test documented?
More hardening (CDN, caching) in the performance guide. Technical baseline on rebuild: web development. For deeper enterprise IT security fundamentals beyond web-specific checklists, Germany's BSI Grundschutz is a solid reference.
Security for AI agent integrations
Websites increasingly embed AI agents: chat widgets or phone callback forms connected to a backend with tool access. That introduces its own security questions that classic web-security checklists don't yet cover.
- API keys and credentials: model and tool access belongs server-side, never in the client bundle. An API key visible in the frontend is in someone else's hands within minutes, regardless of how well the rest of the site is secured.
- Least privilege per tool: an agent that only needs to read a calendar doesn't need write access to the entire CRM. Every connected tool gets exactly the permissions the use case requires, nothing more.
- Prompt injection via untrusted content: if an agent reads a webpage, a document or an email, that content can contain hidden instructions trying to manipulate its behavior. Outputs and triggered actions therefore can't be trusted blindly: critical actions (sending, deleting, paying) need the same human approval as with any other automated system.
- Logging agent actions: classic web logs show HTTP requests, not which decision an agent made or which tool it called and how. An audit trail per agent run (input, intermediate steps, triggered action) is a prerequisite for reconstructing an incident afterward at all.
None of this replaces the fundamentals above, it's an additional layer once a website stops just accepting form submissions and connects a system with its own room to act.
Security headers at a glance
Beyond CSP, these headers block common attacks:
| Header | Protection |
|---|---|
Strict-Transport-Security | enforces HTTPS |
X-Frame-Options / frame-ancestors | clickjacking |
X-Content-Type-Options: nosniff | MIME sniffing |
Referrer-Policy | data leakage via referrer |
On Next.js or static hosting, check whether the host sets headers or you must add them in config.
Incident response without panic
When something goes wrong, you need a short playbook:
- Contain: lock affected accounts, maintenance mode if needed
- Analyse: logs, changed files, recent deployments
- Fix: patch, rotate passwords, remove backdoors
- Communicate: internal immediately, external only for data breaches per GDPR process
- Follow up: document root cause, tighten monitoring
A one-page emergency plan with phone numbers (hosting, IT, privacy officer) saves hours.
Key takeaways
- HTTPS and current software are the minimum
- Server-side validation and CSP stop the most common web attacks
- MFA for admin access is mandatory, not optional
- Backups only matter if restore is tested
- Security and privacy strengthen trust and SEO
FAQ: web security
Is HTTPS enough on its own?
No. HTTPS is the minimum. You also need updates, MFA, server-side validation and tested backups.
How often should I test backups?
At least quarterly, with a documented restore test. A backup without a successful test is worthless.
Do small sites need CSP?
Yes, when dynamic content or forms exist. CSP reduces XSS risk significantly.
What is the fastest security win?
MFA on hosting and CMS, remove outdated plugins, do not expose admin interfaces unnecessarily.
