Website Security Levels: What 884 Smart Audit Checks Showed

A website that opens is not necessarily a secure one. The owner sees the home page, the order form and the catalogue, and concludes that everything is fine. But part of what happens to a website can only be seen from the outside, through the eyes of someone who is checking it.

We launched Smart Audit, a service that looks at other people's websites in exactly this way: passively, and only at public pages. It changes nothing, does not guess passwords and does not try to get inside. At the time of writing we had results for 884 unique company websites, using the latest successful check for each one. We did not pick "good" or "bad" examples: the sample includes online shops, corporate websites, media outlets and sites of large organisations. We name no names, because we are interested in the overall picture, not in specific addresses.

Below is what we saw, what it means for the owner, and where to start fixing it.

The overall picture: 22 points out of 100

The average overall score across all 884 websites is 22 out of 100. By area: security 19, speed 18, search visibility 17.

• 480 websites (54%) scored below 20 out of 100;
• 286 (32%) scored between 20 and 39;
• 96 (11%) scored between 40 and 59;
• only 22 websites (2.5%) reached 60 or higher.

On the security score alone the picture is this: for 466 websites (53%) it is below 10 points, for 652 (74%) it is below 30, and only 75 websites (8.5%) scored 60 or more.

A caveat first, so the numbers are not misread. "22 out of 100" does not mean a website is 22% secure, and even less that it has been hacked. It is the distance from a basic set of checks: whether the site switches on the protections that have long been considered standard. Most points are lost on things that are quick and inexpensive to fix. That is exactly why these numbers deserve attention.

The first layer: doors without latches

Every page the server sends to a browser comes with service "instructions": what this page is allowed to do and what it is not. These are the so-called security headers. They do not make a website impenetrable, but they limit the damage when another hole is found. And here the shortage is almost universal:

• A content security policy (CSP) is missing on 90% of websites. It defines which scripts the browser is allowed to run on the page. Without it, any injected code runs on equal terms with the site's "own". This is how skimmers appear on checkout pages: scripts that quietly copy bank card data. For a shop (and there are 130 of them in the sample), this is the most expensive missing "latch".
• There is no permissions policy (Permissions-Policy) on 93%. It limits what widgets embedded in the site can ask a visitor for: camera, microphone, location.
• There is no referrer policy (Referrer-Policy) on 88%. Without it, the full addresses of your pages, including internal order numbers or tokens in links, are sent to third-party counters and advertising services.
• There is no protection against embedding in other people's frames on 73%. An attacker can show your website in a transparent frame on their own page and trick a person into clicking a "button" that actually sits on your site. This technique is called clickjacking.
• There is no ban on "guessing" the file type on 71% (nosniff).
• HSTS is not enabled on 62%. Without it, a person's first visit may go over an unencrypted channel, and on a public Wi-Fi network that is a chance for the page to be swapped.

To be fair: a missing header does not mean a hacked website. It means a missing layer of protection. But it is fixed with a few lines in the server settings, so its absence almost always says one thing: nobody ever got around to the security settings.

The second layer: what lies in plain sight

This section is more serious. On 172 of 884 websites (19%), almost one in five, internal addresses that were never meant to be public are accessible from the outside. Some websites have several such places at once. The breakdown by type:

• A list of WordPress user accounts: 103 websites (12%). A standard address returns user logins, including administrators. Half of the attacker's work is done: the login is known, and only the password remains to be guessed.
• An internal Git folder: 45 websites (5%). It can be used to restore the website's source code, and the change history sometimes contains passwords and keys that were once "temporarily" written into the code.
• A phpinfo page: 43 websites (5%). It shows PHP versions, modules, server paths and environment variables. For an attacker, this is a ready-made map of the terrain.
• An internal server status page: 34 websites (4%). It shows which addresses visitors are opening right now and from which IPs.
• A .env settings file: 33 websites (4%). Such a file usually holds database passwords and keys for email and payment services.
• A copy of the database: 28 websites (3%). A file someone left in the site root "for a minute": customers, orders, phone numbers, addresses.

It is important to understand that nothing has to be hacked here. Opening the address in a browser is enough. Smart Audit does not go into the contents of these files: it only records that something responds at that address, and the contents are neither read nor stored. But what we do not do, anyone else can, and automated scanners go through such addresses around the clock all over the internet.

The third layer: software that has gone out of date

Among the websites checked, WordPress is the most common at 222 (25%), followed by OpenCart at 88 (10%). For the rest, the platform could not be identified or the site is custom-built.

154 websites (17%) themselves reveal which version of the system they run. This is visible in the service tags on the page. On their own they do no harm; the harm comes from combining them with an old version. Among those that exposed their WordPress version, 22 websites run on branches 4 and 5, released many years ago. For such versions, you should not count on anyone closing new vulnerabilities.

The version of the server itself is a separate matter. On 247 websites (28%), the response headers name the exact versions of the server software. The attacker does not have to guess: they see the version and immediately reach for a method known to work against it. How much this matters is clear from the example of critical PHP vulnerabilities: there, the only defence is a timely update. And for the flip side, what happens when an update is done without preparation, see our breakdown of a plugin auto-update.

The fourth layer: forms and connections, where customer data enters a website

Forms are how a person gives you a name, a phone number, an address and sometimes a payment. That is why how they are built matters most. What we found:

• 489 websites (55%) have forms without protection against request forgery (CSRF). This is when someone else's page can make the browser of your visitor or your administrator submit a form on their behalf, without asking them.
• 543 (61%) have forms that collect personal data without consent to process it. This is not only about security: it is also a matter of complying with personal data law.
• 532 (60%) have forms without bot protection. The result is familiar to anyone who has seen an inbox clogged with spam from "enquiries".
• 76 websites (9%) have forms that pass personal data in the page address (the GET method). The phone number and name stay in the browser history and in server logs, and reach third-party services along with the address.
• 321 (36%) have cookie without protective flags. They are easier to intercept or read with a script.

And a few basics that, you would think, should have been in place everywhere long ago: 35 websites (4%) open with no encryption at all (the browser shows a "Not secure" warning on them), 43 have a certificate that expires soon, and on 36 websites part of the content of a secure page is loaded over an unsecured channel, so the encryption does not fully apply.

What this means for the owner

Setting the jargon aside, there are only a few business risks.

1. Leak of customer data. An exposed database copy or settings file is not a "technical detail"; it is a chance to take your customer list without breaking anything. Next come reputational damage and liability for keeping personal data safe.
2. Someone else's code on your website. Updates that were not installed in time, plus no CSP, and casino ads, redirects to third-party sites or a skimmer on the payment page appear on your pages. You may hear about it from a customer rather than from your own side.
3. A "dangerous website" label and a drop in search. Browsers and search engines do not take risks with visitors. A hacked website can fall in search results for weeks, and getting back takes longer than it took to lose the position.
4. Downtime and the cost of recovery. Recovering after a hack usually costs many times more than prevention would have. And while the website is down, there are no orders.
5. Loss of partners' trust. Large customers and tenders increasingly ask you to show how you handle security. The answer "we don't know" does not earn points.

Where to start: an order that works

1. Close the exposed internal files. These are the most expensive holes, and they are the quickest to fix: an hour of work is usually enough. Files with passwords should be taken out of public access, and the passwords themselves changed afterwards, because they cannot be assumed to be safe.
2. Update the system and plugins and remove exact versions from the server's responses. Update on a copy of the website, not blindly on the live one.
3. Add security headers. Start with HSTS, protection against embedding, nosniff and Referrer-Policy; they almost never break anything. Introduce CSP gradually, first in monitoring mode.
4. Put HTTPS in order: automatic certificate renewal, redirect from http, no unsecured content.
5. Check the forms: a token against request forgery, bot protection, sending only by POST, and clear consent to data processing.
6. Set up off-site backups and monitoring. A backup that sits next to the website disappears along with it in a hack. And website availability should not be checked by your customer.

How we help

Smart Audit answers the question "what exactly is wrong" in the language of priorities: the report separates findings that are visible at once from those built into the website's platform itself. The first kind we close on your current website. The second kind, such as old versions, system limitations and the impossibility of configuring protection properly, are usually solved by moving to our Smart CMS, where security headers, form protection and updates are already built into the core. We carry out the move ourselves: we transfer the pages and addresses, keep the search visibility settings, and help at every stage so that you lose neither traffic nor orders.

Whichever way you decide to start, it is worth first seeing your own picture.

---

You can check your website for free, without registration, in three minutes at audit.sgt.com.ua. And if you would like us to look at the result together with you and say plainly what to fix first, write to us.