Skip to main content

Command Palette

Search for a command to run...

Why I’m Transitioning Into Application Security (and What That Really Means)

Published
3 min read
I

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.

Growing up, I was always fascinated by how things worked behind the scenes.
Even before I knew the terms backend, API, or web application, I was curious about how systems made the frontend feel seamless and even more curious about how something that looked protected could still be bypassed.

Back then, I didn’t know that what I was fascinated by fell under web application security or penetration testing. I didn’t know that a “website” was really a web application, or that bypassing input validation and protections was part of a broader cyber security domain.
But I held on to that curiosity.

The Problem I Discovered as a Developer

When I eventually became a software developer, that old curiosity came back this time with clarity.

I could now build web applications.
I could design APIs.
I could implement authentication.

But I realized something uncomfortable:
I didn’t truly know how to protect what I was building.

While working on backend systems, I started noticing patterns:

  • assumptions that authentication alone was enough

  • authorization logic that lived only in the frontend

  • APIs exposed simply because “users can’t see them anyway”

  • backend logic that worked, but wasn’t hardened against abuse

This became especially clear while working on projects like my DJ booking platform and my escrow MVP, where real-world misuse, abuse, and trust boundaries actually matter.

I could build systems but I didn’t yet know how attackers thought about breaking them.

Why Application Security Called My Name

That realization pushed me deeper.

I enrolled in APIsec University, and it was a turning point.
Learning about the OWASP Top 10 for APIs was a real eye-opener.

One lesson stood out clearly:

Many developers assume that because an API is hidden behind a UI, it is secure.

As a developer, I recognized myself in that statement.
I hadn’t ignored security, I had underestimated exposure.

That single realization changed how I saw everything:

  • APIs are public attack surfaces

  • Security is not inherited from the UI

  • Assumptions are vulnerabilities

From there, I expanded my learning through:

  • TryHackMe (Web Application Security)

  • PortSwigger Web Security Academy

  • Hands-on OWASP-style auditing on my own projects

What started as curiosity became intent.

The Developer → Security Advantage

Transitioning into application security didn’t feel like starting over, it felt like building on a foundation.

My background as a MERN stack developer gives me:

  • an engineering mindset

  • the ability to read and reason about code

  • an understanding of application architecture

  • context for why vulnerabilities exist, not just how to exploit them

Instead of seeing vulnerabilities in isolation, I see how design decisions create risk.

That perspective is what pulled me deeper into application and API security.

What I’m Actively Working On (Real Steps, Not Aspirations)

This transition isn’t theoretical, it’s practical.

Current Projects

  • A delivery company frontend

  • A DJ booking platform, currently being reviewed against OWASP API risks

  • A digital form system for realtors

  • A digital escrow MVP focused on trust and transaction integrity

Current Security Learning

  • APIsec University

  • TryHackMe Web Application Security

  • PortSwigger Academy

  • AltSchool Africa Cybersecurity Diploma

Academic Direction

  • Drafting my first cybersecurity-focused article

  • Actively working toward a research assistant-ship pathway

Where I’m Going Next

My focus moving forward is clear:

  • specializing in application and API security

  • preparing for API-focused bug bounty programs

  • publishing security writeups and case studies

  • building security-aware side projects

  • applying for a research-backed MSc in Cybersecurity

This is not a pivot away from software development.
It’s a deepening of it.

Closing

If you can think it, you can birth it
and I’m building a future where I don’t just create systems,
I secure the systems people depend on.

More from this blog

Kami

9 posts

Technical Writer specialized in API Documentation, User Manuals, and UI/UX Product Design. Skilled in producing clear, precise, and engaging content for various technical documents.