October 24, 2026
You Know How to Write Code, But Is Your Application Secure? A Developer’s Introduction to OWASP
Understanding cybersecurity doesn’t require becoming a security expert. It starts with recognizing the risks hidden in everyday code.

By Kheang Panda
3 min read
As software developers, we spend a lot of time learning programming languages, frameworks, databases, APIs, and deployment technologies.
We know how to build applications, connect services, design databases, and deploy software to production.
But there's one important question we sometimes forget to ask:
Is the application we're building actually secure?
An application can have a beautiful user interface, clean code, excellent performance, and a well-designed architecture, yet still contain serious security vulnerabilities.
For example:
- What happens if someone changes the user ID in an API request?
- Can a normal user access an administrator's endpoint?
- Are passwords and API keys stored securely?
- Could malicious input manipulate a database query?
- Are our third-party dependencies introducing security risks?
These are exactly the kinds of questions that application security encourages us to consider.
This is where OWASP comes in.
1. What Is OWASP?
OWASP stands for Open Worldwide Application Security Project.
It is a nonprofit foundation and open community dedicated to improving software security.
OWASP provides free resources, documentation, tools, and guidelines to help developers and organizations build more secure applications.
One of its most widely recognized resources is the OWASP Top 10, which identifies major security risks affecting web applications.
Think of OWASP as a guide that helps developers understand what can go wrong with an application and how to prevent it.
You don't need to be a penetration tester or cybersecurity specialist to benefit from it.
If you develop frontend applications, backend APIs, mobile applications, or cloud-based services, OWASP is relevant to your work.
2. Why Should Developers Care About Cybersecurity?
Imagine you're developing a hospital management system.
Your application includes patient records, medical histories, appointments, prescriptions, and billing information.
Everything works perfectly during testing.
However, your API exposes an endpoint like:
GET /api/patients/1001
After logging in, a user changes the request to:
GET /api/patients/1002
If your backend returns another patient's information without checking whether the requesting user is authorized to access that record, your application has a security vulnerability.
The problem isn't necessarily your programming language, database, or framework.
The problem is missing authorization logic.
A single mistake like this can expose sensitive information and damage users' trust.
That's why cybersecurity isn't only the responsibility of a security team.
It should also be part of everyday software development.
3. Understanding the OWASP Top 10 (2025)
Here's a beginner-friendly explanation:
Security Risk
What It Means
- A01: Broken Access Control : Users can access information or actions they shouldn't
- A02: Security Misconfiguration : Unsafe application, server, or cloud configurations
- A03: Software Supply Chain Failures: Risks introduced through dependencies, build processes, or software delivery
- A04: Cryptographic Failures: Sensitive data isn't protected with appropriate cryptography
- A05: Injection: Untrusted input is interpreted as a command or query
- A06: Insecure Design: The application architecture lacks necessary security protections
- A07: Authentication Failures: Weaknesses in login, identity verification, or session management
- A08: Software or Data Integrity Failures: Software or data is trusted without appropriate integrity verification
- A09: Security Logging and Alerting Failures: Security incidents aren't properly recorded or detected
- A10: Mishandling of Exceptional Conditions: Errors or unusual conditions create insecure behavior
You don't have to memorize every category immediately.
Instead, begin by understanding how these vulnerabilities appear in real code.
4. Practical Example: Broken Access Control
Let's say you're building an API using Node.js and Express.
You create an endpoint to retrieve user information.
Insecure example:
app.get("/api/users/:id", async (req, res) => {
const user = await db.users.findById(req.params.id);
res.json(user);
});app.get("/api/users/:id", async (req, res) => {
const user = await db.users.findById(req.params.id);
res.json(user);
});The code looks simple and functional.
But there's a problem.
It doesn't verify whether the current user has permission to access the requested data.
If someone changes the ID in the URL, they might retrieve information belonging to another user.
More secure approach:
app.get(
"/api/users/:id",
requireAuth,
async (req, res) => {
const requestedId = req.params.id;
if (req.user.id !== requestedId) {
return res.sendStatus(403);
}
const user = await db.users.findById(requestedId);
if (!user) {
return res.sendStatus(404);
}
res.json({
id: user.id,
name: user.name
});
}
);app.get(
"/api/users/:id",
requireAuth,
async (req, res) => {
const requestedId = req.params.id;
if (req.user.id !== requestedId) {
return res.sendStatus(403);
}
const user = await db.users.findById(requestedId);
if (!user) {
return res.sendStatus(404);
}
res.json({
id: user.id,
name: user.name
});
}
);Here, requireAuth represents properly implemented authentication middleware that verifies the session or token and populates the trusted req.user.
The endpoint then checks whether the authenticated user owns the requested resource. A real application may also need role-based permissions, tenant-level checks, and carefully controlled administrative access.
The important lesson is:
Authentication tells us who the user is. Authorization determines what they're allowed to do.
Both are essential.
_Written by _Chea Kheang — Software Engineer | System Architect | Tech Entrepreneur
Sharing practical knowledge about software engineering, DevOps, cybersecurity, and building reliable systems.