Seven security checks for a business website: six from things we found, one from last month’s news
This is a list of checks, not of products. Six come from something we found at Grafica, on our own domain or on a site we were asked to look at. The first comes from last month’s news. Where the finding was a client’s, the client is not named.
1. Apply core security updates the day they ship
On 22 September 2026 WordPress released version 7.1.2 to fix a critical flaw. An attacker with no account could make a site load a PHP file from elsewhere on the server, outside the folders it was meant to read, and on some setups that can lead to running code. Two days later a security company, Patchstack, was quoted reporting traffic against the flaw at more than ten times the volume of the first evening.
The check: open your dashboard and read the version. It should be 7.1.2 or later. Older branches back to 4.7 received the fix too. If automatic background updates are on, the site should have updated itself. Read the number anyway. If it has not, take a backup with your host’s tool, then update the same day, on a staging copy first if you have one, and ask who turned updates off and why.
2. Ask for your own backup from the outside
On two sites we audited, a full-site backup could be downloaded by anyone who asked for it by its file name.
A backup the public can download is a copy of your site handed to anyone who asks. A full-site backup can hold user records and stored form entries.
The check: find where your backups are written. In a private browser window, where you are not logged in, first ask for an image you know is public in the same area of the site and see it load. That proves the folder answers from outside. Then ask for the backup in that same folder, with the file name copied from your file manager or backup plugin, not typed. The right answer is «not found» or «forbidden». If the backup downloads, have it moved out of the web folder, and have the passwords and keys it contains changed.
3. Remove accounts nobody owns
On one site we found an administrator account, about two months old, that had been created for a one-off job and never removed. It owned no content and nobody owned it.
We did not delete it on sight. We first confirmed it owned nothing, exported the user list, then reduced it to the lowest role and left the deletion to the owner.
The check: list your administrators. For each one, name the person. Any account without a name gets its role reduced and its password reset today, and a decision this week. If nobody recognises it at all, tell your developer or host the same day. Keep at least one administrator you personally sign in with, and ask your developer or host before touching an account a service may be using.
4. Make your domain vouch for its own mail
This one is ours. Until 26 August 2026, mail from our own domain was not fully authenticated. There was no DMARC record and no DKIM key published, and the SPF record did not include the service that sends our mail. What prompted the look: a business partner found a 37-day-old message, carrying a deadline, in his spam folder.
Two details from the fix are worth passing on. The old SPF record already used 9 of the 10 lookups the standard allows, so we replaced it instead of extending it. And we did not trust the DKIM key by eye: it was compared by hash at the source, in the DNS field and in public DNS.
The check: send a message from your business address to a Gmail account, open «Show original» and read three lines. SPF, DKIM and DMARC should each say PASS. Then look up your DMARC record with a public checker, and look up a name that should not exist, to see the tool say so.
5. Protect your forms, then check where the real messages land
On 7 September 2026 automated enquiries arrived through our contact form. We deployed a challenge. In the hours we watched afterwards, none arrived.
Our first two real test messages went to spam. The mailbox had learned from the bot messages that mail shaped like our form’s notification was junk, and it applied the lesson to the first genuine ones.
The check: after you fix a form, send a real enquiry through it and find it in the inbox it is meant for. If it is in spam, the fix is not finished.
6. Close the old doors at the edge
On 26 September 2026 we raised our domain’s minimum TLS version from 1.0 to 1.2 and turned on Always Use HTTPS. Before that second change we read a day of traffic to confirm no client was using DAV methods over plain HTTP, because a redirect can break software that a browser test never shows.
We wrote the rollback first and tested from outside afterwards.
The check: run your domain through a public TLS test. If 1.0 or 1.1 is enabled, ask your host or CDN to set the minimum to 1.2.
7. If you sell online, look at your own payment data
On a WooCommerce store we moved, linked from our Work page, a card-testing attack, the kind that uses a checkout to try stolen card numbers, was found and stopped in the same month as the move. The store’s own database told part of the story: it held far more stored payment tokens than the store had saved cards. Only 486 belonged to real customers, one each.
The check: ask whoever maintains your store how many stored payment methods and customer accounts were created last month, and whether that matches your real orders.
Why the pace matters now
On 30 September 2026 Google announced a new AI model, released first to what it calls trusted cyber defenders, and said that on its own benchmark the model uncovered a wide range of security exposures across complex codebases. Tools that find flaws in code are getting better. Assume the same will be true of tools in other hands, and keep your site patched.
None of the seven checks needs a product. They need someone willing to look. (Our free X-Ray is a different thing: it ranks where AI and automation fit a business. It is not a security audit.)
Want to talk it through?
