From Learning APIs to Protecting Systems

I started learning APIs thinking mostly about how systems connect.

Requests.
Responses.
JSON payloads.
Authentication tokens.

At first it all seemed very technical.

But as I went deeper into API security and penetration testing, something changed.

I stopped looking at APIs as simple connectors between systems.

I started seeing them as critical trust boundaries.

APIs expose business logic, move sensitive data, and allow external systems to interact directly with internal services. When these interfaces are poorly designed, attackers do not need to break encryption or bypass infrastructure security.

They simply use the API exactly as it was built.

One Mindset Shift I Experienced

I stopped thinking about APIs as endpoints and started thinking about them as attack surfaces.

Before studying API security, I assumed that if authentication existed, the system was mostly safe.

Pen-testing showed me that many vulnerabilities come from business logic flaws:

• Broken object level authorization
• Excessive data exposure
• Improper asset management
• Trusting the client too much

In many cases, the system works exactly as designed — but the design itself allows abuse.

That realization changed how I think about software.

One Principle I Now Strongly Believe

Security must be part of the design process, not something added later.

When APIs are designed without security thinking, problems appear everywhere:

• objects exposed without ownership checks
• endpoints leaking internal data
• debug endpoints left accessible
• rate limits missing or misconfigured

Fixing these issues after deployment is difficult because they are tied to how the system was originally built.

That is why security needs to be considered at the product stage, not just during testing.

One Responsibility API Security Professionals Should Never Ignore

Never ignore how a system can be abused.

Developers often ask:

• Does the feature work?
• Does the API return the correct data?

But security professionals must ask different questions:

• What happens if someone calls this endpoint repeatedly?
• What happens if a user changes an ID value?
• What data should never be exposed through this response?
• Can this feature be chained with another weakness?

Those questions are what turn API development into API security.

Looking Back

This journey took me from simply learning how APIs work to understanding how they can fail.

API security is not just about protecting endpoints.

It is about protecting the systems, data, and trust that those endpoints represent.

And that responsibility cannot be treated as optional.