Security3 min read
The web application security checklist we run before every launch
Not a compliance document. This is the list we actually work through before a client site handles its first real user.
The OWASP Top 10 categorises the most critical web application security risks. Broken access control leads the list, followed by cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, integrity failures, logging failures and server-side request forgery.
Broken access control means a user can act outside their permissions — reading another tenant's data by changing an id, calling an admin endpoint directly, or elevating their own role. The fix is always the same: enforce authorisation server-side, at the point of data access, based on the session rather than on anything the client sent.
Cryptographic failures mean sensitive data is exposed through weak or absent protection: passwords stored with a fast hash, personal data transmitted over HTTP, tokens in URLs, or home-grown encryption. Use TLS everywhere, a modern password hash, and vetted libraries — never invent a scheme.
// Injection: user input becomes part of the query
const rows = await db.query(`SELECT * FROM users WHERE email = '${email}'`);
// Fixed: parameterised
const rows = await db.query("SELECT * FROM users WHERE email = $1", [email]);Injection covers SQL, NoSQL, command and template injection — anywhere untrusted input is interpreted rather than treated as data. Insecure design is different in kind: a flaw in the intended behaviour, such as a password reset that reveals whether an account exists, or a checkout that trusts a price from the client. No amount of input validation fixes a design that was wrong.
Logging is the category teams skip because it prevents nothing. It is what determines whether you discover an intrusion in an hour or in the breach notification you receive from someone else.
SSRF happens when your server fetches a URL supplied by a user — an avatar import, a webhook test, a link preview. An attacker points it at internal services or the cloud metadata endpoint and reads credentials your server can reach but they cannot.
No — it is an awareness document of the most critical categories. For a comprehensive standard, use the OWASP Application Security Verification Standard, which is structured for actual verification.
Broken access control, then dependency management. Together they account for a large share of real-world exploitation and both are testable in an afternoon.
Partially. Modern frameworks escape output, parameterise queries through their ORM and set some headers. None of them can decide whether the current user is allowed to see a record — that is always your code.
Manual testing with two accounts for access control, automated dependency and secret scanning in CI, a security header check, and periodic penetration testing if your risk profile warrants it.
ROVQIX Engineering
Engineering team, ROVQIX
The ROVQIX engineering team builds and maintains web platforms, APIs and infrastructure for clients across SaaS, ecommerce and enterprise. These notes come out of real production work — deploys, incidents, migrations and audits.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
Not a compliance document. This is the list we actually work through before a client site handles its first real user.
React escapes text by default, which handles most XSS. The remaining cases are the ones people write deliberately.
Parameterised queries have solved this for twenty years. Injection persists because of the one query someone built with string concatenation.
No spam. Just the occasional case study and craft breakdown.