Website security audit

An outside-in check of how well the site defends its visitors: HTTPS and the certificate, security headers, cookies, mixed content, CORS and the files a deploy should never publish.

• All services

A security audit answers one practical question: what does an attacker see when they look at your site from the outside, and which doors are left open that cost almost nothing to close? SiteScan.top looks at the site exactly the way any visitor or bot can — no access to the server, no agent to install, no changes to the code — and turns what it finds into a list of concrete fixes with a priority on each.

What the audit covers

HTTPS and the certificate. We check that the site answers over HTTPS and redirects plain HTTP there, that the certificate is valid, issued for the right name and not about to expire, that the chain is complete and the signature modern. We list which TLS versions the server still accepts: TLS 1.0 and 1.1 have been withdrawn, and a server that still speaks them fails compliance checks and makes downgrade attacks possible.

Security headers. The response headers decide how much the browser is allowed to trust the page. The audit reads every one that matters:

• Strict-Transport-Security — whether HSTS is on, how long the browser remembers it, whether subdomains are covered and whether the domain qualifies for the browsers' preload list;
• Content-Security-Policy — whether there is a policy at all and whether it actually limits scripts, or allows unsafe-inline and any host;
• X-Frame-Options and frame-ancestors — protection against clickjacking, where your page is loaded invisibly inside someone else's;
• X-Content-Type-Options, Referrer-Policy, Permissions-Policy — the small headers that close whole classes of problems for one line of configuration each.

Mixed content and cookies. A page served over HTTPS that loads a script or an image over HTTP is only as secure as its weakest resource. The crawl reports every such resource on every page it visits. Cookies are checked for the Secure, HttpOnly and SameSite flags: without them a session cookie can travel over an unencrypted connection or be read by a script injected into the page.

CORS and dangerous methods. We send a request from a foreign origin and look at the answer. A server that echoes any origin back and allows credentials lets any page a signed-in visitor opens read your site on their behalf. We also check whether the server answers TRACE, a method no site needs.

Exposed files. A deploy sometimes publishes what it never should: .env with database passwords, the .git folder with the whole source history, SQL dumps and archives, directory listings, JavaScript source maps. Each finding is confirmed by the content of the response, not by the status code alone, so a "200 OK" page that merely says "not found" is not reported as a leak.

Security conventions. The /.well-known/security.txt file tells researchers where to report a vulnerability; change-password lets password managers send users straight to the right form. Neither is mandatory, both are a sign of a mature site.

How it works

You enter the address of the site and start a scan. The scanner opens the pages in a real browser, follows internal links, and runs the checks against the server. Every request is an ordinary request a visitor could make: the audit does not try passwords, does not send exploit payloads and does not put load on the site. A typical scan takes a minute or two.

What you get

The result is a report with an overall security score and a list of findings sorted by severity. Each finding says what was found, on which address, why it matters and how to fix it — usually with a ready-made line of configuration for nginx, Apache or the application. Findings that are a matter of choice rather than a defect (DNSSEC, CAA, HSTS preload) are marked as optional, so they do not drown the important ones.

The report can be shared by link, exported to PDF for a client or a contractor, or copied as a brief for a developer. Add the site to monitoring and the audit is repeated on a schedule: if a release removes a header or the certificate gets close to expiry, you get an email or a Telegram message instead of finding out from users.

Who it is for

The audit is useful before launching a new site, after moving to another hosting provider or CDN, before a penetration test (so that the pentesters spend the budget on real problems rather than missing headers), and as a regular check for agencies that maintain dozens of client sites. It does not replace a full penetration test, but it catches the most common configuration mistakes in minutes and for a fraction of the cost.