As part of my API security learning journey, I worked on a hands-on project where I tested a vulnerable healthcare application called Zero-Health.

The goal wasn't just to run tools or follow steps it was to actually think like an attacker and understand how real-world APIs can be abused when security is not properly implemented.

Setting Up the Lab

I started by cloning the Zero-Health repository and running it locally using Docker.

Once everything was up and running, I confirmed that the API services and database were working correctly.

From there, I accessed the Swagger documentation at:

http://localhost:5000/api/docs

This gave me a full overview of how the API was structured authentication, patient data, chatbot, admin, everything was clearly exposed.

At this point, I already knew… this was going to be interesting.

Recon First — Understanding the API

Before touching anything, I took time to understand the attack surface.

From Swagger, I identified endpoints like:

• /api/login
• /api/register
• /api/patients
• /api/prescriptions
• /api/lab-results
• /api/messages
• /api/chatbot/history

Then I moved to Postman and Burp Suite to capture real requests while interacting with the application.

This helped me see how the API behaves in real time not just what the docs say.

The Big Problem: Broken Object Level Authorization (BOLA)

This was the main issue across almost all endpoints.

After logging in as a normal user, I started testing how the API handles IDs in requests.

So I did something simple.

I changed the id parameter.

And that was it… everything started breaking.

Lab Results

GET /api/lab-results?id=4

I changed the ID and got another patient's lab result.

No validation. No ownership check.

Prescriptions

GET /api/prescriptions?id=5

Same thing I accessed another user's medication records.

Appointments

GET /api/appointments?id

I was able to view appointment schedules that didn't belong to me.

Patients Records (This one was worse)

GET /api/patients?id=21

This endpoint exposed full personal details of multiple users.

At this point, it wasn't just a bug anymore… it was a mass data exposure issue.

Messages

GET /api/messages?id

I could read private conversations between doctors and patients.

Chatbot History

GET /api/chatbot/history?id=user-0

Even AI chatbot conversations were exposed just by changing the ID.

What This Means

All these endpoints had the same issue:

The backend trusted user input without verifying ownership.

So once you are logged in, you can basically become any user just by changing IDs.

In a real healthcare system, this would mean:

• exposure of medical records
• leakage of private conversations
• violation of patient confidentiality

And that's a big deal.

Authentication Bypass Using SQL Injection

After testing authorization, I moved to authentication.

The login endpoint looked normal:

POST /api/login

So I tested it with a simple payload:

' OR '1'='1' --

And guess what…

I got logged in.

Not just logged in I was authenticated as an admin user and received a valid JWT token.

Why This Worked

The backend was directly inserting user input into SQL queries without sanitization.

No prepared statements. No validation.

So the database just executed whatever I sent.

Final Thoughts

What stood out to me the most is how easy it was to move from one vulnerability to access other users accounts.

Just by:

1. logging in
2. modifying IDs
3. testing inputs

I was able to access sensitive healthcare data and even bypass authentication completely.

This experience really helped me understand that API security is not optional it has to be built into the system from the beginning.

If you're building APIs or testing them, always ask yourself:

Am I trusting the user too much?

Because that's usually where things go wrong. Follow me for more content like this.