Common flaws and the fix for each

Grouped like the OWASP Top 10 (2021 edition). The fix column is where to start; most rows need it applied everywhere, not in one place.

Passwords, sessions and tokens

Use a well-known library for each row rather than writing your own. The "Avoid" column lists what still turns up in real code reviews.

Secrets in one breath

Never commit secrets; keep .env in .gitignore and ship a .env.example with fake values. Store real ones in a secret manager or your CI's encrypted secrets, scoped to one environment. Prefer short-lived credentials: GitHub Actions can sign in to the cloud with OIDC instead of a stored key. Turn on secret scanning and push protection. If a secret leaks, rotate it first, then clean history: deleting the commit does not un-leak it, because forks, caches and clones keep copies (Supply chain, Pipeline and AI, Supply chain in CI).

Security headers to start from

Set them once in the web server, CDN or framework middleware. Roll a new CSP out with Content-Security-Policy-Report-Only first and read the reports before enforcing it.

Cryptography: use and avoid

Pick from a maintained library (libsodium, the platform's crypto module, your cloud's KMS). Designing your own scheme is the one mistake reviewers cannot fix with a small patch.

Threat modelling with STRIDE

Draw the data flow first (who talks to what, across which trust boundary), then walk each arrow with the six letters. Four questions frame the session: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job (Threat modelling).

Secure code review: ten questions

• Does every new endpoint check who is calling and whether they may touch this object?
• Is all user input bound as a parameter, never joined into SQL, shell commands or file paths?
• Is output escaped by the framework, with no new raw-HTML sinks?
• Are secrets read from the environment or a secret manager, never written in code or logs?
• Do logs record security events without passwords, tokens, card numbers or full personal data?
• Do errors return a generic message to the client and the detail only to the logs?
• Do new dependencies come from a known publisher, with a pinned version in the lockfile?
• Are uploads limited by size and type, stored outside the web root and scanned or re-encoded?
• Are outbound calls to user-supplied URLs restricted to an allowlist?
• Is there a rate limit on anything that sends a message, costs money or checks a secret?

Logs worth collecting

Collect centrally, keep timestamps in UTC, and know how long each source is retained. Never log passwords, tokens, secrets or full card numbers (Logs).

Alert triage in five questions

Write the answer to each question in the ticket as you go, so the next analyst can pick it up (Triage).

Incident response: the phases

The classic lifecycle from NIST SP 800-61. Small incidents move through it in an hour; the order still matters.

Numbers worth remembering

Check current guidance before you put these in a policy; standards are revised every few years.

Testing your own systems

Only test what you own or have written permission to test, with a signed scope, dates and a contact for when things break. Report findings with steps to reproduce, impact and a fix, ranked by risk, not by how clever they were (Ethics and scope, Reporting).

Glossary

Plain definitions of the security terms used most across the Cybersecurity line.

Attack surface

Every place an attacker could interact with a system: endpoints, open ports, accounts, dependencies, people. Attacker mindset

Authentication and authorization

Authentication proves who you are; authorization decides what you may do. Most breaches of web apps are authorization bugs. Access control

Break-glass account

An emergency admin account kept offline and watched closely, used only when normal sign-in is broken. Identity

CSP (Content Security Policy)

A response header that tells the browser which sources of script, style and frames to allow. JS security

CVE and CVSS

A CVE is the public id of one known vulnerability; CVSS scores how severe it is from 0 to 10. Supply chain

Defence in depth

Several independent layers of protection, so one failure does not expose everything. Attacker mindset

Detection rule

A saved query over logs that raises an alert when it matches suspicious activity. Detections

EDR

Endpoint detection and response: an agent on each device that records activity and can isolate the device. SOC tour

False positive

An alert that fired on harmless activity; too many and analysts start ignoring alerts. Triage

IDOR

Insecure direct object reference: changing an id in a request gets you someone else's record. Access control

Indicator of compromise (IOC)

A trace of known bad activity, such as a file hash, domain or IP address. Threat hunting

Least privilege

Every person, service and token gets only the access its job needs, for only as long as needed. Identity

MFA

Multi-factor authentication: a second proof besides the password, such as a passkey or an app code. Identity

MITRE ATT&CK

A public catalogue of attacker techniques, used to map which ones your detections cover. Detections

Parameterised query

SQL sent with placeholders and the values separately, so input can never change the query's shape. Injection

Passkey

A phishing-resistant login based on a key pair stored on the user's device (FIDO2 and WebAuthn). Identity

Phishing

Tricking someone into giving up credentials or running something, usually by email or message. Breaches

Risk

How likely something bad is, times how much it would hurt; the basis for deciding what to fix first. Risk and incidents

SBOM

Software bill of materials: the list of every component and version inside a build. Supply chain

Secret scanning

Automatic search of code and commits for keys and passwords, ideally blocking the push. Pipeline and AI

SIEM

Security information and event management: the central place where logs are collected, searched and alerted on. SOC tour

SOC

Security operations centre: the team that watches alerts, triages them and responds to incidents. SOC tour

Supply chain attack

Getting into your systems through something you depend on: a package, a CI action, a vendor. Supply chain

Threat model

A structured look at what you are building, what can go wrong and what you will do about it. Threat modelling

Trust boundary

A line in a data-flow diagram where data passes between parts with different levels of trust, such as the internet and your API. Threat modelling

Zero trust

Checking identity and device health for every request instead of trusting anything inside the network. Networks and cloud

Courses on Kolom

• Security Foundations: how attackers think, identity, cryptography, networks and risk, without assuming you code.
• Application Security for Developers: access control, injection, sessions, threat modelling and the supply chain in your own code.
• Defensive Security: SOC, Detection and Response: logs, detection rules, triage, hunting and incident response.
• Offensive Security: Ethical Hacking and Pentesting: scoped, legal testing and reports that get fixes made.

What to read next

• OWASP Top 10 at owasp.org/Top10. The list behind the first table, with examples and prevention for each category.
• OWASP Cheat Sheet Series at cheatsheetseries.owasp.org. Short, practical pages on password storage, sessions, CSP, input validation and much more.
• OWASP ASVS at owasp.org. A checklist of security requirements to test an application against, in three levels.
• NIST SP 800-63B at pages.nist.gov. The source of modern password and MFA guidance.
• MITRE ATT&CK at attack.mitre.org. Attacker techniques with detection ideas; pairs with Detections.
• Threat Modeling: Designing for Security by Adam Shostack. The book behind STRIDE practice and the four questions.