Site security in one evening: 10 steps you can check yourself

Small sites are rarely hacked by someone hunting for you personally. It is bots that spend days trying the same weak spots: short passwords, old versions, an admin panel at the default address, open registration. Close those spots and your site stops being an easy target. Below are ten steps for one evening. Each has three lines: what to do, how to check it yourself (a screen or a command), and what happens if you skip it.

This is not a “click everything” list: the steps are independent, take them one at a time. The engine does part of the work itself: for example, it sends the security headers to the browser (step 5), so all you have to do is make sure they arrive.

Your control panel: “Site protection” #

Open “System → Security → Site protection”. It is one screen that shows what is fine, what is worth tightening and what is bad. Every row explains itself and leads to the place where it is fixed. Almost every step below is checked by a row on this screen.

It is a hint, not a verdict: the figures are counted on the fly from your site's data.

Step 1. Updates #

What to do. Open “System → Updates” (the page is visible to those who have the site-settings right: the owner and administrators) and update if there is a new version. Make a database backup before updating (step 8): the engine makes one by itself, but a manual copy costs nothing. How to check. The same page shows which version you have and whether a new one exists. Look there once a week, where you check orders or mail. If you skip it. Holes that are already closed in the new version stay open on your site, and everyone knows about them: a fix is published together with a description of the bug.

Step 2. Password and password guessing #

What to do. In “Site settings → Sign-in and users → Registration and users” set “Minimum password length” to 10 characters or more (this is the default). Length alone does not save you, but the engine rejects obvious passwords separately. Then in “Security → Login and sessions” make sure “Sign-in attempts” is no more than ten. By default it is five failures, after which sign-in to that account is closed for 15 minutes (the time is set in “Lock for, minutes”), and a bot hits the limit. How to check. On the “Site protection” screen the rows “Password length” and “Lock-out after failed sign-ins” should be “Good”. If you skip it. Short passwords and unlimited attempts make guessing a matter of time. It is the simplest way to break in, and two numbers close it.

Step 3. Two-step sign-in #

What to do. In your own profile turn on the second step (“Enable 2FA”): a code from an app on your phone confirms the sign-in. Save the “Backup codes”: each works once and you need them if you lose the phone. Then ask the same of every administrator. When everyone is used to it, in “Site settings → Sign-in and users → Security → Admin access” switch “Two-factor protection” from “Recommend” to “Require for administrators”. It will not lock you out: the engine sends everyone who has no second step yet to their profile to turn it on, and the profile is always available. So there is nothing to be afraid of. How to check. The row “Two-step sign-in for administrators” on the “Site protection” screen; the “Users” list has a “Two-step sign-in” filter that shows who still has it off. If you skip it. A password can be stolen not from you but from some other service where you used the same one. Then, without the second step, the way into the panel is open.

Step 4. Encrypted connection (HTTPS) #

What to do. Make sure the site has a certificate and opens over https://. Only then, in “Site settings → Sign-in and users → Security → Connection”, turn on “Secure connection only (https)”. Do not turn it on without a certificate: the redirect would send visitors nowhere. How to check. Open the site at an address starting with http://: the browser should move to https://. The same on the command line:

curl -I http://example.com

Expect code 301 or 302 and a line Location: https://example.com/. The row “Encrypted connection (HTTPS)” on the “Site protection” screen should be “Good”. If you skip it. Passwords and sessions travel in plain text: in someone else's public network a stranger can read them.

Step 5. Security headers #

What to do. Almost nothing: the engine sends them itself. Your task is to make sure a proxy or hosting in front of the site does not strip them. How to check.

curl -I https://example.com

The response should contain these lines:

• X-Content-Type-Options: nosniff: the browser does not guess a file's type;
• X-Frame-Options: SAMEORIGIN (on some pages DENY) and, in Content-Security-Policy, frame-ancestors 'self': another site cannot put your page in a frame;
• Referrer-Policy: strict-origin-when-cross-origin: extra parts of the address do not leave the site;
• Permissions-Policy: camera, microphone and geolocation are off until they are needed;
• Strict-Transport-Security: max-age=31536000 over https: the browser remembers to use the secure connection only.

You can also see a grade on the public Mozilla Observatory check (developer.mozilla.org/en-US/observatory). Do not chase the top grade: it sees neither outdated software nor weak passwords, and it does not replace a check. If you skip it. Nothing breaks at once: these headers only tell the browser what to forbid. But the more of them there are, the fewer mistakes elsewhere turn into a problem.

Step 6. Panel address and access by address #

What to do. In “Site settings → Sign-in and users → Security → Admin access” enter a “Custom admin address” (Latin letters, digits, a hyphen), make up your own, do not copy the example in the picture below. Write it down next to your password. The “Allow the admin panel only from these addresses” field is only for those with a permanent address (for example, an office with its own address): from other addresses the panel answers “no such page”. A home or mobile address usually changes, and then you end up outside the door yourself: a list without your current address cannot be saved, but tomorrow the address may be different. Without the panel the restriction can be lifted only with the command php nex1on admin:access on the server. Without access to the server console and without a permanent address it is better not to turn this field on.

How to check. Open the new address: the sign-in should open. The old /admin should answer “no such page” (404). The rows “Address of the admin panel” and “Panel access by address” on the “Site protection” screen will reflect it.
If you skip it. Nothing terrible happens, but bots find the panel at the default address first, and the noise in the log grows. A custom address does not replace the password and the two-step sign-in, it only takes you off the list of easy targets.

Step 7. Who can do what and who registers #

What to do. Open “Users & access → Users” and see who has which role. An administrator should be someone who needs it every day; an editor is fine with the editor role. If you do not need visitor registration, turn off “Allow registration” in “Site settings → Sign-in and users → Registration and users”; if you do, leave “Require email confirmation” on. How to check. The “Users” list and each person's role; the row “Visitor sign-up” on the “Site protection” screen. If you skip it. Extra rights turn someone else's mistake or a stolen password into a big problem. Open registration without email confirmation lets anyone create accounts with other people's addresses.

Step 8. Copies: the database and off the site #

What to do. Make a database copy in “System → Backups and transfer → Database backups” and set up an automatic one. Set up “Off-site copies” (an encrypted copy outside the server): if the hosting disappears, a copy next to the site disappears with it. More about backups and moving: “Backups and moving a Nex1on site”. The uploads folder is copied separately (over FTP): it is not part of a database copy. How to check. The list “Existing backups” should have a fresh one. For the off-site copy press “Test connection”, and when the first copy arrives, open it on your computer and tick “I opened a copy on my computer and the key works”. If you skip it. This is the only step where a mistake cannot be fixed later: lost entries and orders cannot be brought back by anything.

Step 9. Spam and API keys #

What to do. In “Security → Spam guard” keep the strict mode (the default). In “Integrations → API access keys” revoke keys nobody uses: a needed key can be issued again, while a forgotten one stays a door. How to check. The rows “Spam guard” and “API keys” on the “Site protection” screen: the second reminds you of keys not used for more than 90 days. If you skip it. Spam fills your forms, and a forgotten key may remain an access that everyone has forgotten about for years.

Step 10. Two minutes a week #

What to do. Once a week open “Site protection” and “Security → Security events”. It takes two minutes: you do not have to read the log, it is enough to see that the rows are green and failed sign-ins have not become noticeably more frequent. How to check. The row “Failed sign-ins in 24 hours”: “Good” while there are fewer than thirty. Many sign-ins from one address can be blocked in “Security → IP blocking”. If you skip it. You learn about a problem from visitors rather than from the site.

What this list does not do #

It reduces the risk, it does not remove it completely. It will not protect you from a bug in a third-party module or in the hosting's software, and it does not replace a backup. If in doubt, consult a specialist, especially when the site stores payments or other people's personal data.