The Invisible Shield: 5 Golden Rules That Protect a System From Attack

Building a certificate database for education centres was not simply writing code — it meant taking on a great responsibility. The system held the personal data of more than 1000 students, along with their work and their achievements. Behind numbers like that lies the trust of real people. And that means only one thing: there is no room for error at all.

Security is not an accident; it is continuous discipline. Drawing on the bitter and valuable lessons of penetration testing, I want to share five practical steps that turn a system into an unassailable fortress.

1. Paranoia is a virtue: never trust input

Every $_GET, every $_POST and even the most harmless-looking HTTP header arriving from outside is a potential attack vector. Treat any data sent to your site as a box with a bomb hidden inside.

Strict validation and typing. Every entry point must have a checkpoint standing on it.

Prepared statements. When working with a database this is not merely a recommendation — it is the non-negotiable bare minimum.

2. The cheapest but sturdiest armour: HTTP headers

This layer of defence, which many developers overlook, is in fact one of the largest obstacles in an attacker's path. The following five lines of code shrink the system's attack surface so dramatically that it almost looks like magic:

Content-Security-Policy: default-src 'self'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin

3. The secret seal: CSRF tokens

Any request that changes a user's state (POST, PUT, DELETE) needs a secret seal — a token bound tightly to the session. It is a very easy rule to remember, but do you know what forgetting it leads to? The quiet, traceless theft of a user's account.

4. XSS: the betrayal happens on output, not input

When Cross-Site Scripting (XSS) comes up, most people go looking for the mistake in how data is written to the database. No — XSS is not an input problem, it is an output problem. How you store the data in the database matters far less than how you escape it before showing it to the user in HTML. Poisoned code has to be neutralised before it is ever read.

5. Attack your own fortress yourself

Running a targeted penetration test before launching the system means staying one step ahead of attackers. Take this as a golden rule: every vulnerability you find now is a vulnerability attackers will not find after the system goes live.

In closing: the harmony of speed and security

The system we built scored even better than expected in Google Lighthouse analysis: 97/100 Performance, 100/100 Best Practices, 96/100 Accessibility.

Many people assume that security measures slow a site down. But the results proved that security and speed are not enemies. They are the beautiful outcome of clean code, sound architecture, and one and the same discipline.