The Cybersecurity Mindset in Everyday Development

My degree is in Cyber Security from Binus University. While most of my career has been in fullstack development, that security background fundamentally shapes how I approach every line of code. It is not about being paranoid — it is about thinking in threat models.

Thinking like an attacker

The most valuable thing my security education gave me was not a specific tool or technique — it was a way of thinking. When I look at a login form, I do not just see a UI component. I see an attack surface. SQL injection vectors. Brute force entry points. Session fixation opportunities. Timing attacks on password comparison.

This mindset does not slow me down. It makes me faster, because I build security in from the start instead of bolting it on later. Retrofitting security is always more expensive than designing for it.

The OWASP checklist I actually use

The full OWASP Top 10 is important, but in my day-to-day web development, there are five vulnerabilities I check for on every pull request:

1. SQL Injection — even with ORMs, raw queries sneak in. Always parameterize.
2. XSS (Cross-Site Scripting) — React helps with JSX escaping, but dangerouslySetInnerHTML and href attributes are still dangerous.
3. Broken Access Control — the most common vulnerability I find in code reviews. Always verify permissions server-side, never trust the client.
4. Sensitive Data Exposure — API responses that return full user objects instead of curated DTOs. Check what your endpoints actually return.
5. Security Misconfiguration — default credentials, verbose error messages in production, CORS set to wildcard. The boring stuff that causes breaches.

Practical security in Node.js

// Bad: string interpolation in queries
const user = await db.query(
  `SELECT * FROM users WHERE id = ${userId}`
);

// Good: parameterized queries
const user = await db.query(
  'SELECT * FROM users WHERE id = $1',
  [userId]
);

// Bad: returning full user object
res.json(user);

// Good: curated response
res.json({
  id: user.id,
  name: user.name,
  email: user.email,
  // password_hash, reset_token, etc. never leave the server
});

Security as a team sport

The biggest security improvements I have driven were not technical — they were cultural. At Prestisa, I introduced a simple rule: every PR that touches authentication, authorization, or payment logic requires a second reviewer. Not because we did not trust each other, but because security-critical code deserves extra eyes.

Security is not a feature you ship once. It is a practice you maintain every day, in every commit, in every code review.

What developers should learn about security

You do not need a security degree to write secure code. But you should understand the basics: how authentication tokens work, why HTTPS matters, what CORS actually protects against, and how SQL injection exploits function. Spend a weekend on PortSwigger Web Security Academy — it is free and it will change how you see your own code.

---

Security is not about being perfect. It is about raising the cost of attack above the value of what you are protecting. For most web applications, following basic security hygiene puts you ahead of 90% of the internet. Start there.