Skip to content
WebAuditOS
Start free audit

Test your website now

Free, no card. We read only public pages.

Run free audit →

Security

How do you secure a website?

The security basics every website needs, in order: HTTPS, updates, authentication, secrets, headers, backups and monitoring.

To secure a website, serve everything over HTTPS, keep software and dependencies updated, protect logins with strong authentication and rate limits, keep secrets out of the browser and code repository, add security headers, restrict who can access admin areas and the database, and keep tested backups. Then monitor, because security is maintained, not finished.

Published · Last updated

By Michal Měřínský. Audit methodology.

Start with what attackers try first

Most attacks on ordinary websites are automated: bots scanning for outdated software, default passwords, exposed admin panels, leaked keys and open databases. The essentials below close those doors. They matter more than any advanced measure.

The essentials, in order

  • HTTPS everywhere, with HTTP redirecting to it and HSTS once it works.
  • Updates: the framework, CMS, plugins and dependencies. Most compromised sites ran known-vulnerable versions.
  • Authentication: strong passwords, two-factor authentication for every admin account, rate-limited login and password reset.
  • Secrets: API keys and database credentials live in server-side environment variables, never in frontend code or the repository.
  • Access control: every API route checks that the user may do what they ask, and database rules, such as row level security, enforce it again.
  • Security headers: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, frame protection and Permissions-Policy.
  • Cookies: session cookies set HttpOnly, Secure and SameSite.
  • Exposure: no directory listings, no stack traces on error pages, no admin panels linked publicly, no version numbers in headers.
  • Backups: automatic, stored separately, and actually tested by restoring.
  • Monitoring: error tracking, uptime alerts and a security.txt so researchers can report problems.

Extra risks in AI-built apps

  • API keys pasted into frontend code to make a feature work.
  • Supabase or Firebase databases with open rules, readable by anyone holding the public key.
  • Endpoints that trust a user ID sent from the browser instead of the session.
  • No rate limits on AI features, which turns abuse into a bill.

Ask your AI tool to explain how each endpoint checks permissions. If it cannot answer clearly, review that endpoint yourself.

What a scan can and cannot tell you

WebAuditOS checks what is visible from outside: HTTPS and redirects, certificate and TLS, security headers and CSP quality, cookie flags, CORS, mixed content, directory listings, error disclosure, version leaks, public admin links, third-party scripts and security.txt.

It cannot see whether passwords are hashed properly, whether your API checks permissions, whether database rules are enforced, whether dependencies have known vulnerabilities, or whether backups restore. Those need code review, dependency scanning and access to your infrastructure.

A perfect external score means no scored issue was found within the observed scope; some controls are checked only for presence. It is not proof the application is secure.

Short answers

What is the most important website security step? Keeping software updated and admin logins protected with two-factor authentication.

Do small sites get attacked? Yes. Automated bots attack everything they can reach.

Is HTTPS enough? No. It secures the connection, not the application.

How often should I check security? After every significant release, with automated checks in between.

In the product

The checks this maps to

Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.

Security

Security headers: what each one does, and what it breaks

What HSTS, CSP, X-Frame-Options, nosniff, Referrer-Policy and Permissions-Policy actually do, the order to add them in, and what each one breaks on the way.

Security

How can you tell if a website is safe?

The checks that tell you whether a website is legitimate before you buy or sign up: the address, reputation, company details, payment options and red flags.

Privacy

What should a website privacy policy include?

What a privacy policy needs to say, what it must match, where to link it, and why a generic template copied from another site creates more risk than it removes.