Security basics for beginners

Why a beginner needs this

Not to become a security specialist. To avoid writing a hole through ignorance — and to answer the interview question that gets asked almost every time.

The five problem types below cover the overwhelming majority of what appears in learning projects and small production ones.

1. Injection into database queries

The best known. It arises when user data is pasted into query text:

query = "SELECT * FROM users WHERE name = '" + name + "'"

Put a specially constructed string in the name field and you can change the query's meaning, read other people's data or drop the table.

What not to do: concatenate strings, "escape it yourself", filter for bad words.

What to do: parameterised queries, where data travels separately from the query text:

cursor.execute("SELECT * FROM users WHERE name = %s", (name,))

Every decent database library supports this. If you use an object-relational mapper, it does it for you.

2. Running someone else's code in a browser

Arises when text entered by one user is shown to another without treatment. The text may contain code that executes in the victim's browser.

What to do: don't insert user text as markup. Modern interface libraries escape by default — the problem appears when a programmer deliberately bypasses that to "insert as-is".

If inserting markup is genuinely required (say, you allow formatting), pass it through a proven sanitiser.

3. Missing permission checks

The most frequent in real projects and the most underrated.

The classic: an address like "/orders/42" shows an order and nobody checks whether it's yours. Change the number and read other people's orders.

What to do: check permissions on every data access, not merely hide buttons in the interface. A hidden button protects nothing: the address can be called directly.

The rule: if a user can supply an identifier, verify the object belongs to them.

4. Weak password storage

Passwords in plain text, or reversibly encrypted. Covered in its own article, but briefly: dedicated password hashing functions only, and a proven library only.

5. Secrets in code

Keys and passwords that reached the repository. Also a separate topic, but worth naming: it's the most common finding in learning projects.

A few more essentials

Rate limiting. A login form without limits is an invitation to guess passwords. A simple attempt limit closes most of the problem.

Protection against forged requests. A mechanism preventing another site from submitting a request as your user. Frameworks provide it out of the box — don't switch it off.

Updating dependencies. A significant share of vulnerabilities arrive through old library versions. Check at least occasionally.

Don't show error details to users. A call stack and server paths are a gift to anyone probing for weaknesses. Details to the log, a general message to the user.

What to say at interview

Beginners get the security question in a gentle form: "which vulnerabilities do you know". Naming three or four from the list above and explaining the defence is enough.

It sounds considerably better if you can add: "in my project I used parameterised queries and permission checks on every access, and keys live in environment variables". That's practice rather than theory.