Security: what I am learning

Security is the part of engineering I am learning now. I am not a security specialist, and this note does not pretend otherwise. It records where I stand, with examples from my projects rather than intentions, and it will grow as I go.

Where I start from

Building web, mobile and backend applications puts you on the defending side of most security problems: authentication, user input, data access, secrets, dependencies. Those are the places where an application meets the outside world, so they are where I look first. My licence project, a guidance platform with accounts and messaging, even made me list data protection among its limits.

What I already apply

Here is what I can show, project by project.

On Minguili, a published app.

• Passwordless login with a one-time code: valid for ten minutes, stored as a hash and not in clear, limited to five attempts, with a delay before asking for another.
• A fifteen-minute access token kept in memory only, a refresh token in the phone’s secure storage and renewed on every use.
• Prices never come from the app: the server recalculates the quote, so a tampered client cannot pay less.
• Authenticated payment webhook, state re-read from the source, idempotent processing.
• At start-up, the server refuses to run with a dangerous configuration in production.

On the basketball league application.

• No sign-up page: the first administrator account is created from a machine that has access to the database.
• Brute-force counter stored in the database, because on stateless hosting the server’s memory is not enough.
• Uploaded logo checked by its bytes and not by what it claims to be, size limited, SVG containing a script refused.
• Automatic reading of match sheets sends the whole photo to a provider: I wrote that in black and white in the documentation, so the league can decide knowingly.

On this site.

• The dashboard only listens on the local machine, hashes the password with scrypt, requires a CSRF token and checks the origin and the host header.
• Uploaded files are checked by their signature and served with a policy that forbids any script.
• Security headers, a security.txt file, and no tracking script.
• I never copy a secrets file from one project to another. A repository can be read, its keys cannot.

What I want to learn next

Applying good practice is not the same as thinking like someone who attacks. That is the part I want to work on: modelling a system’s threats before writing it, understanding how common flaws are exploited, and reading code to find them.

The plan is simple: practise on deliberately vulnerable labs, then apply each lesson to the code I ship. I will list the labs, courses and readings here once I have done them, with what each taught me and what I changed afterwards.

What this note does not say

It does not say my applications are secure. I am not presenting any independent audit of these applications, and this site, being static, exposes very little. What I defend here is a habit: treating security as part of the work and writing down what I do not know yet.