ZEKASTRA

Training module

Securing a website you run

For site owners: HTTPS, security headers, forms, dependencies and the admin account, ordered by how much risk each removes.

15 minutes Intermediate

What you will be able to do

  • Order website defences by effect.
  • Read what a missing header means.
  • Know the three classic input flaws and the one habit that prevents them.

Start with the access, not the code

Most compromised small sites were not broken through clever code flaws. They were entered through a weak administrator password, an outdated plugin or a leaked key. So the first tasks are a unique administrator password with multi-factor authentication, the minimum number of accounts, and automatic updates for the platform, themes and plugins.

HTTPS everywhere

Serve every page over HTTPS, redirect HTTP to it and add a Strict-Transport-Security header so browsers do not even attempt plain HTTP. Mixed content, such as a script loaded over HTTP, breaks the guarantee.

Security headers

Headers let the site tell the browser how to behave. A Content-Security-Policy limits where scripts may load from and so reduces the damage of a cross-site scripting flaw. X-Content-Type-Options stops the browser guessing content types, a frame-ancestors directive or X-Frame-Options stops other sites framing yours, and Referrer-Policy limits what is sent to other sites. Cookies that carry a session need the Secure, HttpOnly and SameSite attributes. The header audit tool in this section checks a pasted set and explains each finding.

One habit against the classic input flaws

SQL injection, cross-site scripting and many similar flaws share one cause: data from a user is treated as part of an instruction. The habit that prevents them is to keep data and instructions apart. Use parameterised queries for databases, encode output for the place it is placed (HTML, attribute, URL), and validate input against what the field should hold. Frameworks do this by default if you do not bypass them.

Access control and dependencies

Check on the server side that the signed-in person may see the record they ask for; hiding a button is not access control. Keep a list of the libraries and plugins you use and update them; a vulnerable dependency is as exposed as your own code. Back up the site and test the restore.

Key points

  1. Admin access, updates and HTTPS first; headers next.
  2. Keep data and instructions apart.
  3. Check permissions on the server, always.

Check yourself

Choose an answer to see the explanation. You can start again at any time.

1. A product page shows another customer's order when the number in the address is changed. Which flaw is this?

The server did not check that the order belongs to the person asking for it.

2. What is the most reliable defence against SQL injection?

They keep user data out of the query's structure, which removes the cause rather than hiding symptoms.

3. Why does a Content-Security-Policy with unsafe-inline in script-src offer little protection?

The policy exists to stop injected scripts; allowing inline scripts removes that effect.

Go further

Sources

This section is for defence and learning. Do not test systems you do not own or have written permission to test: unlawful access to an information system is an offence (Turkish Penal Code, Article 243).