Why Writing Code Is Not the Same as Writing Secure Systems
I’m a software developer and technical writer focused on building and securing web applications. I work across the full stack (MERN) while developing a strong interest in application and API security.
My background in technical writing and API documentation shaped how I think about systems, clarity, structure, and correctness matter as much in code as they do in documentation. I’ve worked with tools like Postman, Swagger, and Figma, and I enjoy translating complex technical ideas into clear, usable knowledge.
These days, I’m learning and writing about web fundamentals, backend systems, and application security, documenting what I build, what I break, and what I’m learning along the way, with an eye toward secure, scalable software and future research.
When I first became a software developer, my focus was simple: make things work.
If the API returned the right data, the UI rendered correctly, and users could complete their actions, I considered the job done. Like many developers, I believed security was something you added later, maybe with authentication, maybe with a firewall, maybe with HTTPS.
I was wrong.
What I later discovered is that most serious security failures don’t come from “bad code”, they come from correct code written without a security mindset.
The Hidden Gap Between Functionality and Security
A system can:
authenticate users correctly
return valid responses
pass all happy-path tests
…and still be fundamentally unsafe.
Why?
Because security lives in relationships, assumptions, and edge cases, not just syntax.
As I began building backend systems and APIs, I noticed recurring patterns:
endpoints that worked perfectly for valid users, but never asked who should be allowed to access what
APIs that trusted frontend behavior instead of enforcing rules server-side
identifiers that made sense for UX, but created unintended exposure risks
error handling that assumed “valid input” would always arrive
None of these were obvious bugs.
They were design blind spots.
The Shift: From “Does It Work?” to “Can It Be Abused?”
My perspective changed when I started auditing my own applications through an application-security lens.
Instead of asking:
“Does this endpoint return the correct data?”
I started asking:
What assumptions does this endpoint make?
What happens when those assumptions are violated?
Is access based on roles, or on actual relationships between users and resources?
Can this logic fail safely, or does it fail loudly?
This was the moment I realized that security is not a feature, it’s a design discipline.
Why Developers Accidentally Build Insecurity
Most insecure systems are not built by careless developers. They’re built by productive developers optimizing for speed.
Common patterns include:
trusting that “the UI won’t allow that”
assuming authentication automatically implies authorization
focusing on correctness, not misuse
treating errors as edge cases instead of attack surfaces
These decisions make sense when your goal is shipping features.
They become dangerous when systems handle money, identity, or trust.
This is how well-intentioned code turns into legal, financial, or reputational risk, not because developers are negligent, but because security was never part of the mental model.
What Writing Secure Code Actually Means
Writing secure systems doesn’t mean:
memorizing vulnerabilities
becoming paranoid
slowing development to a crawl
It means:
designing APIs that enforce rules independently of the frontend
validating intent, not just input
handling failure as carefully as success
assuming your system will be used in ways you didn’t anticipate
Security-aware development is about anticipating misuse, not just enabling use.
Why This Matters to Me
As someone who builds systems and studies how they fail, I’ve learned that the most valuable security insights often come from developers auditing their own work.
That feedback loop => build → audit → redesign, is what turns “working software” into resilient systems.
It’s also what sparked my deeper interest in application security, API security, and research around how architectural decisions introduce hidden risk.
Final Thought
You can write code that works.
You can even write code that scales.
But if you don’t ask how it can be misused, you’re not writing secure systems, you’re just writing optimistic ones.
And optimism is not a security strategy.