DVRA Security Project

Environment: Kali Linux Terminal, I used curl on this project
Target: Damn Vulnerable RESTaurant API (DVRA)

Broken Object Level Authorization (BOLA) is an API vulnerability that allows an attacker to bypass access control mechanisms and perform actions on specific objects without proper permissions. Typically, objects are accessed using unique identifiers such as integers or UUIDs. An attacker with an access to these identifiers can read, modify, or delete related objects. This vulnerability occurs when an API endpoint fails to properly check whether a user has permission to access the requested object. This issue is commonly referred to as IDOR (Insecure Direct Object Reference).

Example:
If you can change:

/orders/1 → /orders/2

and see someone else’s order → BOLA vulnerability

IDOR (Insecure Direct Object Reference)

IDOR is a type of BOLA where:

The application exposes object IDs directly and does not validate ownership.

Example:

GET /orders/5

If you can access order 5 without owning it → IDOR attack

Broken Authentication

Broken Authentication risks are focused on authentication aspects, not authorization.

This occurs when:

• Login/session handling is weak
• Tokens can be forged or reused
• Identity is not properly verified

Example:

• Using a fake or modified token to access another account

JWT (JSON Web Token)

JWT is used for authentication.

• The token is a JWT token sent in the HTTP request by the user.
• The token is decoded via jwt.decode method.
• If the token is succesfully decoded and user exists in the database, the user object is returned.
• If the token is not decoded succesfully or if the user doesn't exist in the database, the function raises HTTPException with 401 Unauthorized status code. It results in the HTTP 401 response sent to the client.

Structure:

HEADER.PAYLOAD.SIGNATURE

Example payload:

{
  "sub": "user1",
  "exp": "user"
}

Tools like jwt.io allow you to:

• Decode tokens
• Modify payloads
• Re-sign tokens (if weak security)

Setting Up Damn-Vulnerable-RESTaurant-API-Game

In Kali Linux terminal:

git clone https://github.com/theowni/Damn-Vulnerable-RESTaurant-API-Game.git
cd Damn-Vulnerable-RESTaurant-API-Game
sudo ./start_app.sh

API runs on:

http://localhost:8091

Register Users

I had 2 users, “Gamu” and “Blee,” that I had created, so I could see the different responses and for the exploitation of any vulnerabilities on different endpoints. On this project, I was just testing out BOLA and Broken Auth.

It is important, as you register or explore endpoints, that you use the schema provided on each endpoint, because if you don’t, it will give you an error.

Create Users with this command:

curl -X POST http://localhost:8091/register \
-H "Content-Type: application/json" \
-d '{
  "username":"user1",
  "password":"pass123",
  "phone_number":"123456789",
  "first_name":"User",
  "last_name":"One"
}'

LOGIN (Broken Auth Learning)

VERY IMPORTANT:
/token uses form data, NOT JSON

Endpoint:

POST /token

curl -X POST http://localhost:8091/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=user1&password=pass123"

Response:

{
  "access_token": "JWT_TOKEN",
  "token_type": "bearer"
}

Save this token:

export TOKEN="your_token_here"

or
vi tokenfile.txt

Access Profile + Test Authentication (Broken Auth)

Test Profile endpoint Without Token, I had forgotten to put it in “URL”

With the Credentials I used to create accounts, I went to the website and tried the Authorization. It did not give me much information.

Endpoint:

What to check:

• If it returns user data → 🚨 Broken Authentication, it does expose the Broken Authentication. But do check it out
• If it says unauthorized → ✅ secure

GET /profile

curl -H "Authorization: Bearer $TOKEN" \
http://localhost:8091/profile"

You should see the attacker profile, which in this instance was “Gamu.”

WHAT THIS MEANS

• Token = your identity
• If API doesn’t check token → broken auth

8. Exploiting Broken Authentication (JWT Manipulation)

Step 1: Decode Token

Go to:
jwt.io

Paste your token.

You’ll see:

{
  "sub": "user1",
  "exp": "1234567"
}

I also wanted to check what happens if you leave the payload open on the ‘sub’, will it return anything

Modify Payload

Change:

"role": "Blee"

To:

"sub": "admin"

Re-sign Token

If DVRA uses weak signing (or none), you can:

• Use none algorithm OR
• Re-sign with known secret

Result

• Access to the admin endpoint, which I couldn’t exploit, is still in the process of being exploited
• Privilege escalation, that's what we want

This confirms:
✔️ Broken Authentication
✔️ JWT Misconfiguration, as we could modify with different ‘sub.’

Create Orders (Setup for BOLA)

Endpoint:

If you do not use the correct schema provided on the endpoint, you will get an error. Ensure you use the schema, then edit the string

POST /orders

curl -X POST http://localhost:8091/orders \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "delivery_address":"Test Street",
  "phone_number":"123456",
  "items":[1,2],
  "coupon_id":1
}'

Look for:

"id": 1 and also "user_id": 19

Exploiting BOLA / IDOR (Orders Endpoint)

Changing the object ID reveals data, which I am not supposed to get PII. Personally Identifiable Information (PII) is data that can identify, contact, or locate a specific individual, such as social security numbers, full names, biometric records, or email addresses. It is crucial for protecting privacy and preventing identity theft

Endpoint:

GET /orders/{order_id}

Attack

1. Get your order:

curl -H "Authorization: Bearer $TOKEN" \
http://localhost:8091/orders/1

1. Change ID:

curl -H "Authorization: Bearer $TOKEN" \
http://localhost:8091/orders/2

Result

• You can view another user’s order
• No ownership validation is performed

This confirms:
✔️ IDOR vulnerability
✔️ BOLA vulnerability

Fix Authorization

• Enforce role checks on every endpoint
• Never trust client input for roles

This project demonstrated how insecure API design leads to:

• Unauthorized data access (BOLA/IDOR)
• Privilege escalation (Broken Authentication)
• Token abuse (JWT weaknesses)

Using Kali Linux, curl, and jwt.io, we successfully:

• Intercepted and modified requests
• Accessed other users’ data
• Escalated privileges to admin

I also did a demo video, so do check it out and share feedback.

Welcome to my API Hacking series, as we learn and exploit different vulnerabilities. For now, enjoy this first of many

https://youtu.be/DfdDkd9EDpc?si=YQOFDboboF9gCX0S

I don’t know if you’ve seen the video of the lady talking about the “AI + U” concept, where the heading of the video is, “AI can never copy her.”

Honestly, that video makes me laugh, BUT at the same time, it makes me sit down and think deeply. I understand her. Especially when she says, “People worry a lot about AI… what about YOU?”

That part stayed with me. Because if you initially think about it, you don’t fully understand what she’s trying to say. For the majority of us, the “Artificial Intelligence” conversation can be super confusing, especially the way it’s being propagated, as this new “human” that is there to take over humanity. Take over my JOB… The need to worry.

Because the truth is, we are worrying about AI, but we are not really asking ourselves where we stand in all of this. The man in the video tries to explain, but there’s already a misunderstanding happening. And I feel like that’s exactly where we are right now as people, we are misunderstanding the change that AI is bringing. The damage, the good, the lay-overs and adjustments…

It is changing so rapidly that as soon as you think you’ve got it, something new pops up, especially in the tech world. And change can be hard, because with change we need to ensure we adjust, understand, and learn, but we’re not always doing that, we trying to keep up, that soo much is being missed in the way

There’s a lot of noise about “AI is replacing jobs,” “AI is taking over,” but not enough people are really breaking it down and explaining what AI actually is in a way that everyone can understand and engage with.

If you Google the definition. It will tell you that AI is the simulation of human intelligence by machines, learning, reasoning, and making decisions. But for me, it goes deeper than that.

Because we are still at a point where we are teaching people about the internet. People are still learning how to use computers, how to protect themselves online, and what it even means to have a digital footprint. There is still a gap, a huge gap, especially when it comes to security around it.

And now we are introducing AI on top of that.

I call it an introduction because even ME, I am still learning and trying to understand it properly. So I think about someone who doesn’t even fully understand the internet yet, what happens when they hear, “AI is going to replace humans”?

That fear is real. And we have to understand that not everyone has the same privilege of being exposed to information, especially when there is already such a huge gap still trying to be filled. Lack of education is soo many part of the world, it is still a major issue. Also, just because I have a device, I understand how it works, just because I am online doesn’t mean I am informed. This is a reality for many. They are using AI Agents, or they are using the internet, but are they properly AWARE of everything?

And it comes from a place of not being included, not being taught, not being prepared. Seeing the damage that is happening around, based on LACK such awareness when it comes to “This new digital world and use of AI.”

Living in a small town myself, where life is still simple and laid-back, there isn’t much conversation about technology, data protection, or cybersecurity. These are not everyday topics for people, and I can only imagine how many parts of the world are still “behind,” trying to adjust.

So when AI comes in, it doesn’t come with understanding, it comes with confusion, fear, and sometimes even silence.

And that’s dangerous.

Because people will end up being part of something they don’t understand. What we might call “consumers,” the ones who may not be prepared because they don’t have the skills for the world of AI. And that’s where the idea of “replacement” starts to come into play.

I sat down and had to break it down in a simple way — for myself, and for anyone else who is also interested in understanding it.

The “A” in AI stands for Artificial, which means something created by humans. So already, we know this is not something natural. It is something built “something made” an addition or formation.

Then the “I” stands for Intelligence, which is about learning, thinking, and solving problems.

So for me, AI is simply this:
“Humans used their intelligence to create something that can mimic their intelligence.” To be honest, that is beautiful.

But here’s where it gets deeper.

That “intelligence” didn’t just come from nowhere, it came from us. That is the “U” I believe, where it comes into play.

Our data.
Our behavior.
The way we speak.
The way we search.
The way we solve problems.
Our digital footprint, technically everything.

That’s where the “U” comes in. The collection of our data is in everything.

Because when I really think about it, AI is not just Artificial Intelligence. It is Artificial Intelligence built from YOU. You + Me = Us… so somewhere it should have been AI+U

Your digital footprint is part of it. Without you in it, it is not really as powerful as it seems. It needs YOU. Just like we need water to live, it needs data to be effective, OUR DATA.

And that’s something I feel like we are not talking about enough.

We are feeding systems every day, through social media, searches, apps, devices and many times, we don’t even realize it. Some of it we agree to, some of it we don’t fully understand, and some of it happens without us even noticing.

So when we say AI is powerful, we must also understand, it is powerful because of us.

But now, let’s also talk about something else that I think isn’t mentioned:

AI is not neutral.

If the data it learns from is biased, then the system becomes biased. If certain communities are not represented, then the system will not understand them. That means AI can make unfair decisions without even “knowing” it.

So now the question is not just, “What is AI?”
It becomes, “Who is included in AI?”

Because if we are not included, then decisions will be made about us, without us. And that is dangerous.

We’ve already seen things like deepfakes, where people’s faces, voices, and identities are used to create things they never said or did. And this is not something far away, it’s here, and it’s growing. A simple example: if you doom-scroll, a large portion of content is AI-generated. It is becoming more real than ever, to the point where people are competing with it. We even give our images so we can get AI-generated ones, the storing of such, are we in agreement with it or aware?

Imagine someone using your face, your voice, your identity for something harmful.

That’s why awareness is important.
That’s why protection is important.
That’s why education is important.

As people build AI agents, are they thinking about security? Or only how to make something “better, faster…”? Encouraging the systems in place to adjust with it, from our government, education system, healthcare, etc., to name a few.

Now coming back to the video again, the lady says, “No, the letter U.”

At first, it sounds like a joke. But the more I think about it, the more it makes sense.

There is a “U” in AI.

Not in spelling, but in meaning.

Because AI cannot exist without people.

There is a “you” behind every system:

the one who created it
the one whose data trained it
and the one who is using it

That is all of us.

But here is the problem, the “U” is there, but it is hidden.

Hidden in terms and conditions we don’t read, and often don’t understand.
Hidden in the data we don’t know is being collected. Our trust is being abused due to a lack of integrity from platforms.
Hidden in systems we don’t fully understand.

So now we are part of something, but we don’t feel part of it.

And that’s where the fear comes in.

I use AI myself. It helps me a lot — with learning, understanding, even thinking through things. It’s not all bad. There is a lot of good in it.

But at the same time, I am learning that if we are not careful, we can easily become just consumers instead of creators.

And that’s something we need to change.

We need to start asking:

Are we teaching this in schools? Is the system adjusting as well?
Are we preparing young people for this world? All people, in different parts of the world
Are communities being included, or does it feel like, “as long as I benefit, it doesn’t matter”?
Are governments putting policies in place to protect people, and do people even know about them?

Am I aware of my rights when it comes to AI data breach, where do I report, and who takes accountability for it? Am I being protected and considered in such production?

Or are we just moving forward and hoping for the best?

Because if we don’t slow down and include people, then AI becomes something controlled by a few instead of something that benefits everyone. It may look like it benefits everyone, even when it doesn’t.

And we’ve seen before that when power is not shared, it can be misused.

There’s also another side that we don’t always talk about.

People say, “AI will replace us.”

But I don’t fully believe that.

I believe people are constantly evolving. No one can ever be completely replaceable.

New jobs will come. New opportunities will come. But at the same time, new risks will also come, especially when it comes to cybersecurity, identity, and trust.

And if we are not prepared, that’s where the real danger is.

Because it won’t just be about jobs, it will be about safety.

I remember when I started my cybersecurity journey, one thing that stayed with me was this:
In any situation, people come first.

Not systems. Not technology. But people.

And I feel like that’s something we need to bring back into this conversation.

Because in all of this growth, all of this innovation, we cannot forget the human being.

I’m sharing this as my thoughts. Not as an expert, but as someone who is learning, observing, and trying to understand.

And I really hope that people like me, young people, students, communities, are included in these conversations. That we don’t just hear about AI, but that we are part of shaping how it is used. That we are invited into spaces where we can sit with experts, learn from them, and grow into people who can bring solutions. Not Consumers only

Because the truth is, no one understands everything.

We understand better when we come together.

After speaking to a friend who asked me, “Why does it bother you?” I had to really think about it.

And I realized it’s not just about being replaced.

It’s about being left out. Trust is broken by how everything is done…

It’s also about the lack of access to knowledge in different parts of Africa, being underrepresented in all of this, in the Tech fields, and not being protected.

It’s about people being at risk because they were never taught, never prepared, never included.

And that’s something we can change.

If we share knowledge.
If we open spaces for learning.
If we bring people into the room, we truly involve them.

Because this world belongs to all of us.

And if we don’t stand together, we risk building something that ends up harming us.

It’s like setting a fire in a house and thinking it won’t reach you, until it does.

So I’ll leave you with this:

Maybe the “U” is missing… It’s just hidden in AI + U.

Do you see it too? Or do you see it differently? What are your thoughts?

Introduction

As someone currently learning Web Penetration Testing, this Practical Bug Bounty from the TCM Security YouTube channel was extremely informative and practical.

Learning alongside Heath Adams and Alex helped me understand not only how to perform attacks, but also why they work and what developers often overlook.

This course focuses specifically on bug bounty hunting through web applications, covering:

• Authentication attacks
• Authorization & Access Control
• API Security
• File Inclusion attacks
• Basic Injection concepts
• Reconnaissance & Information Gathering

Unlike theory-based courses, this one required setting up a real lab and actively exploiting vulnerabilities.

What is Web Application Security?

Before diving into exploitation, the course defined web application security and why it matters.

A web application is essentially any website you interact with:

• Google
• Facebook
• E-commerce platforms
• Banking portals

Every web application handles some form of data often sensitive data.

Why Web Application Security Is Important

• Data Protection — Prevents theft of user information, payment details, and confidential records.
• Regulatory Compliance — Avoids fines and legal consequences.
• Financial Protection — The average breach can cost millions.
• Brand Reputation — Trust takes years to build and seconds to lose.
• Intellectual Property Protection — Prevents trade secrets and proprietary code theft.
• Identity Theft Prevention — Protects personal information from misuse.

As ethical hackers and bug bounty hunters, the goal is to identify weaknesses before malicious attackers exploit them.

Lab Environment Setup

I performed all labs locally in a Kali Linux virtual machine.

Step 1 — Installing PimpMyKali

Repository:
https://github.com/Dewalt-arch/pimpmykali

PimpMyKali automates post-install configuration of Kali Linux.

Installation Process

cd /opt
sudo git clone https://github.com/Dewalt-arch/pimpmykali
cd pimpmykali
sudo ./pimpmykali.sh

I accepted the default prompts and allowed the script to configure everything automatically.

This saved time and ensured my penetration testing environment was fully prepared.

Step 2 — Installing Docker

sudo apt install docker.io docker-compose

After installation, I restarted the VM to ensure all services were running correctly.

Step 3 — Setting Up the Practical Bug Bounty Lab

After downloading the lab ZIP file:

unzip bugbounty.zip
cd bugbounty
sudo docker-compose up

This pulled the necessary images and built the vulnerable lab.

In another terminal:

./set-permissions.sh

This step was important for file upload labs.

Accessed lab at:

http://localhost

If needed, database reset:

/init.php

I frequently reset the database to repeat attacks and reinforce understanding.

Authentication Attacks

Before attacking, I learned the difference between:

• Authentication → Who you are
• Authorization → What you’re allowed to do

Lab 0x01 — Brute Force

Target account: Jeremy

Using Burp Suite

1. Intercepted login POST request.
2. Sent to Intruder (Ctrl + I).
3. Marked password field.
4. Loaded SecLists password list.
5. Analyzed response length differences.

Found valid password: letmein

Using ffuf (Faster Method)

Saved raw request to file:

ffuf -request lab.txt -request-proto http \
-w /usr/share/seclists/Passwords/Common-Credentials/xato-net-10-million-passwords-1000.txt \
-fs 1814

Filtered by response size to detect anomalies.

Successfully identified valid credentials.

Lab 0x02 — MFA Logic Flaw

Target: Jessamy / pasta

After entering correct credentials, the system requested an MFA code.

Observations:

• MFA code was short.
• Username was submitted again during second step.

Exploit

1. Intercepted MFA POST request.
2. Modified the username parameter.
3. Forwarded request.

Successfully logged in as another user.

Vulnerability Type:

Logic flaw in multi-step authentication.

The system failed to bind MFA verification to the original authenticated session.

Lab 0x03 — Account Lockout Bypass

The application locked accounts after 5 failed attempts.

Instead of brute forcing one user:

Strategy:

• Used Burp Intruder.
• Selected Cluster Bomb attack.
• Loaded username list.
• Used 4 common passwords.
• Avoided exceeding 5 attempts per account.

Successfully logged in as admin:letmein

This demonstrated bypassing weak lockout mechanisms.

Authorization & Access Control

Three types of access control covered:

• Vertical (admin vs user)
• Horizontal (user A vs user B)
• Context-dependent

IDOR Lab (0x04)

URL contained:

?account=1001

Exploit

1. Sent request to Repeater.
2. Modified account ID.
3. Accessed other users’ data.

Used Intruder with generated numeric list to enumerate accounts.

Filtered results by searching for “admin”.

Discovered multiple admin accounts.

Using ffuf

ffuf -u http://localhost/labs/e0x02.php?account=FUZZ \
-w num.txt -mr "admin"

Found valid admin IDs.

Vulnerability: Insecure Direct Object Reference (IDOR)
(API equivalent: Broken Object Level Authorization)

API Security & JWT Testing

APIs made up most of the lab traffic.

API 0x01 — JWT Analysis

Logged in via API endpoint.

Received JWT token.

Noticed:

• Header
• Payload
• No proper signature validation

Decoded token manually using Burp Decoder (Base64 decode).

Broken Function Level Authorization

Steps:

1. Logged in as Jeremy.
2. Retrieved token.
3. Updated Jeremy’s bio (expected behavior).
4. Used Jeremy’s token to update Jessamy’s bio.
5. Request succeeded.

Confirmed broken authorization.

Jeremy should not be able to modify Jessamy’s data.

Autorize Extension

Installed Autorize extension in Burp.

Although it required Jython setup, I tested access control by sending requests through the extension and analyzing bypass/enforced results.

This helped automate horizontal authorization testing.

File Inclusion Attacks

File Inclusion 0x01 — Basic LFI

Tested:

../../../../etc/passwd

Successfully retrieved system file.

File Inclusion 0x02 — Filter Bypass + RFI

Initial traversal blocked.

Bypass technique used:

....//....//....//etc/passwd

Filter removed partial sequences but payload reconstructed successfully.

Also tested:

https://www.google.com

Confirmed Remote File Inclusion capability.

PHP Filter Wrapper Exploit

Used:

php://filter/convert.base64-encode/resource=db.php

Decoded response in Burp.

Extracted database credentials.

API-Based LFI (0x03)

Saved API request.

Fuzzed with ffuf:

ffuf -request api-req.txt -request-proto http \
-w /usr/share/seclists/Fuzzing/LFI/LFI-Jhaddix.txt

Filtered by word count and response size.

Identified working payload.

Confirmed LFI via API endpoint.

What I Learned

• Always step through functionality manually first.
• Response length and word count matter.
• Logic flaws are often more dangerous than brute force.
• Broken Access Control is extremely common.
• JWT misuse is widespread.
• Filters must be recursive and properly validated.
• Resetting labs and repeating attacks improves understanding.
• Mental fatigue affects testing accuracy breaks are important.

This course significantly improved my practical web penetration testing skills.

Built the lab environment from scratch.

Used Burp Community effectively.

Used ffuf for faster fuzzing.

Tested authentication and authorization thoroughly.

Exploited API vulnerabilities.

Performed LFI and filter bypass attacks.

Extracted sensitive credentials.

Understood real-world impact of vulnerabilities.

Most importantly, I didn’t just watch the walkthrough I actively performed the attacks, reset the database, and repeated exercises until I fully understood them.

This course strengthened my bug bounty methodology and confidence in testing real-world web applications. I will be doing the remaing labs, as they have many more, do check it out.

check it out on the @TCM Security:

https://youtu.be/wS2z5lt34Cc?si=pkbO1ICzo8WfZm-j

Room 1: OWASP Top 10 (2025) — IAAA Failures

The first room in the TryHackMe OWASP Top 10 (2025) module focused on IAAA Failures, covering A01, A07, and A09. This room was clearly designed with beginners in mind, assuming no prior security knowledge, which made it an excellent foundation for understanding how core identity and access mechanisms can fail in real-world applications.

The room introduces IAAA as a simple but powerful mental model for thinking about how users and their actions are handled in web applications:

• Identity — the unique account representing a user or service (such as a user ID or email).
• Authentication — proving that identity (passwords, OTPs, passkeys).
• Authorisation — defining what that identity is allowed to do.
• Accountability — recording and alerting on who did what, when, and from where.

One key idea that really stuck with me is that IAAA is sequential. You can’t skip steps. If identity or authentication is weak, authorisation and accountability become meaningless. Each layer depends on the one before it.

A01: Broken Access Control

Broken Access Control occurs when the server fails to properly enforce what a user is allowed to access on every request. This isn’t about hiding buttons in the UI, it’s about whether the backend actually checks permissions.

A common example discussed in the room is IDOR (Insecure Direct Object Reference). If changing a parameter like ?id=7 to ?id=6 allows you to view or modify another user’s data, access control is broken.

In practice, this leads to:

• Horizontal privilege escalation — accessing other users’ data while having the same role.
• Vertical privilege escalation — gaining access to admin-only functionality.

The underlying problem is trust. When applications trust client-side input instead of enforcing server-side checks, attackers can manipulate requests to do things they were never meant to do.

A07: Authentication Failures

Authentication failures happen when an application cannot reliably verify or bind a user’s identity. The room demonstrated how surprisingly small logic flaws can completely undermine authentication.

Common issues include:

• Username enumeration
• Weak or guessable passwords
• Missing rate-limiting or account lockout
• Flaws in login or registration logic
• Insecure session or cookie handling

One particularly interesting example involved trying to break into the admin account. Since the username admin was known, the challenge explored registering a user with a differently cased version like aDmiN. This highlighted how failing to enforce canonical identity handling can allow attackers to bypass authentication controls and bind sessions to unintended accounts.

If authentication isn’t implemented carefully, attackers don’t need advanced exploits — they can simply log in as someone else.

A09: Logging & Alerting Failures

The final category tied everything together through accountability. Even if an attack happens, defenders still need to be able to detect, investigate, and respond. That’s impossible without proper logging and alerting.

Logging and alerting failures show up as:

• Missing authentication success/failure logs
• No visibility into privilege changes
• Vague or unhelpful error messages
• No alerts for brute-force attempts
• Logs stored locally where attackers can modify or delete them
• Short log retention periods

This room made it clear that logging isn’t just a compliance checkbox — it’s what enables accountability. Without it, organizations may not even realize they’ve been compromised.

Key Takeaways

By the end of this room, I had a much clearer understanding of how failures in Identity, Authentication, Authorisation, and Accountability directly map to some of the most critical vulnerabilities in the OWASP Top 10 (2025):

• A01 Broken Access Control: Always enforce server-side authorisation checks on every request.
• A07 Authentication Failures: Canonicalise identities, enforce unique indexes, rate-limit or lock out brute-force attempts, and rotate sessions after password or privilege changes.
• A09 Logging & Alerting Failures: Log the full authentication lifecycle, centralise logs off-host with proper retention, and alert on suspicious behaviour like brute-force bursts or privilege escalation.

This room set a strong foundation for the rest of the module and reinforced how fundamental IAAA is to secure web application design. When these basics fail, the impact can be severe — allowing attackers to access other users’ data or gain privileges they were never meant to have.

CheckOut the room on TryHackMe: https://tryhackme.com/room/owasptopten2025one

You can also watch the walkthrough video here:

https://youtu.be/F0ojrvbcNLk?si=8se7kFQk4RrdcKq2

Dearest gentle reader,

This is not the story of someone who already knows everything, it is the story of someone learning in public.

I am currently on my journey into Web Application and API Penetration Testing, and along the way, I’ve learned that security is not about memorizing tools or exploits. It’s about curiosity. It’s about asking why things work the way they do, and what happens when they don’t.

Before I ever try to exploit a vulnerability, I want to understand the foundations, how websites are built, how data flows, and where trust quietly breaks. This article is my attempt to slow down, revisit the basics, and document my understanding as it grows. This is the beginning of it.

If you’re also learning web security, just starting out, or simply curious about how the web works behind the scenes, you’re in the right place. Let’s begin at the beginning, not as experts, but as students of the craft.

What Is Web Application Security?

Web application security is the practice of protecting websites, web services, and APIs from attacks that could lead to:

• Unauthorized access
• Data breaches
• Account takeovers
• System compromise

Some common attacks include SQL Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and insecure configurations.

At its core, web application security focuses on protecting:

• The users
• The data
• The systems behind the application

But to protect something, you must first understand how it works.

How a Website Works (In Simple Terms)

When you type a website address into your browser and press Enter, a conversation begins.

1. Your browser (Chrome, Firefox, Edge, Safari) sends a request
2. A web server receives that request
3. The server processes it
4. The server sends a response back
5. Your browser displays the page

That server is simply another computer somewhere in the world whose job is to handle requests.

Every web application is built from two main parts:

• Front End (Client-Side)
• Back End (Server-Side)

Understanding this separation is critical for security.

Front End (Client-Side): What the User Sees

The front end is everything you interact with in your browser.

Websites are mainly built using:

HTML — structures the page (forms, buttons, text, images)

CSS — controls appearance (colors, layouts, fonts)

JavaScript — adds logic and interactivity

This is the part of the application that runs inside the user’s browser.

Important Security Truth

Anything on the front end can be seen by the user.

You can view it by:

• Right-clicking → View Page Source
• Pressing Ctrl + U
• Opening Developer Tools
• Using tools like Burp Suite

This visibility is where many security problems begin.

Sensitive Data Exposure

Sensitive Data Exposure happens when a web application exposes confidential information directly to the user.

Examples include:

• Hardcoded usernames or passwords
• API keys inside JavaScript files
• Hidden admin URLs
• Debug messages
• HTML comments containing credentials

Sometimes developers forget to remove test data or temporary credentials. An attacker reviewing the page source could find this information and use it to:

• Log into restricted areas
• Access backend systems
• Escalate privileges

This is why viewing page source is one of the first steps in web penetration testing.

User Input: The Root of Many Vulnerabilities

Most web applications accept user input:

• Login forms
• Search boxes
• Comment sections
• Profile updates

If this input is not handled properly, vulnerabilities appear.

HTML Injection

HTML Injection occurs when user input is displayed on a page without being filtered or sanitized.

If a website trusts user input and renders it directly, an attacker can inject HTML code such as:

• Fake login forms
• Malicious links
• Page manipulation

This allows attackers to control how content appears to other users, which can lead to phishing and deception.

HTML Injection is often the first step toward more serious attacks.

Cross-Site Scripting (XSS)

XSS is a more powerful form of injection where attackers inject JavaScript instead of just HTML.

When malicious JavaScript executes in a victim’s browser, attackers may:

• Steal session cookies
• Take over accounts
• Perform actions as the victim
• Redirect users to malicious websites

Types of XSS

Reflected XSS
User input is immediately reflected in the response
Example: search results or error messages

Stored XSS
Malicious input is saved in the database and shown later
Example: comments, posts, profile bios

DOM-Based XSS
JavaScript modifies the page using unsafe user input
Example: vulnerable page titles or dynamic content

Even though XSS runs on the client-side, its impact can be severe especially if administrators are targeted.

Cross-Site Request Forgery (CSRF)

CSRF tricks users into performing actions they did not intend to perform.

If a user is logged in and visits a malicious page, an attacker can:

• Change passwords
• Update account details
• Perform privileged actions

This works because browsers automatically send session cookies with requests.

CSRF attacks are especially dangerous when used against admin users, as admin actions can affect the entire application or server.

Why Front End Vulnerabilities Still Matter

Although front end vulnerabilities do not directly compromise the server, they:

• Endanger users
• Enable account takeovers
• Can be chained with other vulnerabilities
• Often lead to backend compromise

Security is never about one bug — it is about how vulnerabilities connect.

Defending the Front End

Two critical defenses when handling user input:

Input Validation

Ensure input matches the expected format
Example: emails must look like emails

Input Sanitization

Remove or escape dangerous characters before display or storage

Additional protections include:

• Web Application Firewalls (WAFs)
• Browser security features
• Anti-CSRF tokens
• SameSite cookies
• Re-authentication for sensitive actions

These should be treated as layers, not replacements for secure coding.

Back End (Server-Side): Where Logic Lives

The back end processes requests, enforces rules, and manages data.

• Handles authentication and authorization
• Communicates with databases
• Executes business logic

Servers respond using HTTP status codes such as:

• 200 OK — Success
• 401 Unauthorized — Not authenticated
• 403 Forbidden — Access denied
• 404 Not Found — Resource missing
• 500 Internal Server Error — Server failure

Understanding these responses is essential during penetration testing.

Databases: Where Data Is Stored

Web applications use databases to store:

• User credentials
• Posts and content
• Files and images
• Configuration data

Databases must be protected because compromising them often means full data exposure.

APIs: Connecting Front End and Back End

APIs allow the front end to communicate with the back end.

An API (Application Programming Interface) defines:

• What actions can be performed
• What data is accepted
• What responses are returned

Common HTTP methods:

• GET — Retrieve data
• POST — Create data
• PUT — Update data
• DELETE — Remove data

APIs are powerful and when insecure, they can expose entire systems.

Common Web Application Vulnerabilities (OWASP Top 10)

Some of the most common issues found during penetration testing include:

Broken Authentication & Access Control

• Login bypasses
• Privilege escalation
• Unauthorized admin access

Malicious File Upload

• Uploading executable scripts
• Leading to remote code execution

Command Injection

• Injecting OS commands
• Gaining server-level access

SQL Injection (SQLi)

• Manipulating database queries
• Bypassing authentication
• Dumping sensitive data

Web application security is not just about tools or exploits it is about understanding systems deeply.

As I continue my journey into Web and API Penetration Testing, I am learning that:

• Most vulnerabilities come from simple mistakes
• Small misconfigurations can have massive impact
• Strong security starts with strong fundamentals

This is only the beginning of my journey — and I look forward to learning, breaking, fixing, and sharing every step along the way.

Until next time,
Happy hacking (ethically). 🖤

A Reflection on Community, Collaboration, and the Future of Africa’s Cybersecurity

With great gratitude and excitement, I am honoured to share that I attended the 2025 AfricaCERT Symposium in beautiful Mauritius, my second year being invited and sponsored by AfricaCERT to represent CyberSafe Foundation. Every year, this event reshapes how I think, how I learn, and how I show up in the cybersecurity community. It is one thing to attend a conference; it is another to be in a space where your mind is stretched, your curiosity is fed, and your potential is taken seriously.

Each time I leave this Symposium, I walk away with a renewed sense of purpose, carrying more knowledge than I arrived with and holding a deeper appreciation for the extraordinary people around the table. I am particularly inspired by Mr. Jean-Robert Hountomey’s remarkable ability to bring together such a large, impactful event, uniting experts, leaders, and young professionals from across the continent. His commitment to ensuring that we all leave with the same mission to strengthen African cybersecurity and, ultimately, protect our societies is truly admirable.

Because truly, the people in that room are more than attendees. They are brilliant African innovators, defenders, thinkers, researchers, and leaders, each one pouring into the next with intention, generosity, and a shared vision for a safer, more resilient Africa.

Celebrating 15 Years of Impact and 10 Years of Partnerships

This year’s Symposium was especially meaningful as AfricaCERT celebrated:

• 15 years since its formation, and
• 10 years of partnerships across Africa and globally.

In that time, AfricaCERT has become a cornerstone of the continent’s cybersecurity ecosystem, building capacity, strengthening incident response teams, enhancing collaboration, and driving cross-border knowledge-sharing. The impact has touched governments, institutions, communities, and young people like myself. I am proud that this influence also extends to my own community, CyberSafe Foundation.

My hope is to see even more women and more young African talent in these spaces because the blend of seasoned wisdom and youthful innovation is exactly what our continent needs.

My heart is filled with gratitude to have gotten to celebrate such an amazing milestone with FIRST and AfricaCERT. 10 years of partnership is not a joke, you can already see the trust, impact, and influence this has.

Key Message of the Symposium: Stop Gatekeeping — Defenders Must Unite

One message echoed loudly across multiple sessions was the need to end gatekeeping in our industry.

Cybercriminals share knowledge.
They collaborate.
They exchange tools, ideas, and vulnerabilities.

So why shouldn’t we, the defenders, do the same?

If Africa is to stand strong, we must build:

• trusted relationships,
• stronger communication channels,
• cross-border cooperation, and
• a united intelligence-sharing culture.

Because no single organisation, government, or individual can secure an entire continent alone.
But united defenders can.

Track 1: Investigating Ransomware Through Windows Artifacts and Event Log Correlation — with Mr Chireh Mohamed Abdi, and Yacin Djibril Waberi.

My first session was a hands-on exploration of ransomware investigation, and it was packed with technical depth and real-world insights.

We covered:

• Ransomware classifications — from encryption-only attacks to double and triple-extortion strategies.
• MITRE ATT&CK TTP mapping for ransomware operators.
• Data exfiltration channels, including C2 servers, cloud services, RDP, and specialised tools like MegaSync and WinSCP.
• Deployment methods such as GPOs, PsExec, and C2 orchestration.
• Ransomware response using the NIST Framework, from preparation to post-incident review.
• Windows forensic techniques, including RAM imaging, disk acquisition, event log analysis, and artifact triage.

The day concluded with a full ransomware investigation lab, which tested our analytical skills and incident response thinking. Truly one of the most eye-opening sessions of the Symposium.

Track 2: Enhancing CSIRT Capability through the SIM3 Maturity Model with Mr Olivier Caleff

This track was one of my favourites because it felt more like a conversation than a lecture. We explored the SIM3 maturity model, learning what true CSIRT maturity looks like not in theory, but in practice.

Key insights included:

• Understanding internal vs external CSIRT constituencies.
• Identifying service gaps and maturity weaknesses.
• The importance of validated, measurable, repeatable processes.
• Requirements under RFC 2350 (IETF).
• The updated FIRST CSIRT Services Framework.
• Governance, documentation, escalation paths, and performance measurement.

This track helped me understand not just what a CSIRT is supposed to do, but how to evaluate its maturity with honesty and transparency.

Track 3: Hands-On Network Threat Detection Training for Critical Infrastructure using Security Onion — with Mr. Howard Mukanda, Mr. Ezeckiel Dadjo, Mr. Luc Semassa.

Although I joined a little late, I quickly caught up because the session was incredibly rich. We explored:

• Hardware requirements for Security Onion.
• Cloud deployment considerations.
• Remote management using Redfish scripting.
• Observability tools like Grafana and Zabbix
• IT/OT visibility challenges.
• Real-world troubleshooting practices.
• Malware Traffic Analysis.
• The importance of reliable, high-quality data sources.

Security Onion is more than a SIEM it is an ecosystem. Seeing it in action renewed my appreciation for visibility and network-level forensics.

A Message on Protecting Our People and Their Data

The Mauritian Minister of IT, Communication and Innovation delivered a powerful reminder:

We are no longer protecting computers — we are protecting people.

He spoke about:

• Respecting personal data
• The dangers of sharing images and private information without consent
• Social media is becoming a threat when used irresponsibly
• Digital awareness as a societal responsibility
• The need for Africa to stand as one against cybercrime

We also received a book titled “AI for All”, which reflects where Africa is heading an inclusive, responsible AI future.

When Cyber Attacks Meet the Physical World: OT Cyber Risks Reduction: What Leaders Need to Know by Ms. Michelle Govender.

This session reframed cybersecurity for me.
When an OT system is compromised, the damage is not digital it is physical.

Key takeaways:

• OT environments cannot afford downtime.
• IT/OT collaboration is essential but often lacking.
• Visibility in OT systems is critical for safety.
• Cyber incidents in OT can have national consequences.
• Governance, communication, and readiness must be aligned.

It reminded me that cybersecurity is not only about protecting networks, it is about protecting lives, industries, and national stability.

Strategic Playbook for Safeguarding the National Critical Infrastructure by Ms. Sithembile Songo.

This session explored the blueprint for protecting Africa’s most essential systems.

We discussed:

• Defence-in-depth strategies.
• Risk-based standards.
• The unique security model of OT.
• Inter-sector collaboration.
• Insurance, continuity, and resilience planning.

The message was clear:
Africa must work together to protect what keeps our nations running.

Celebrating Youth Excellence — CyberDrill Designed by Young African Talent

One of the most inspiring parts of this year’s Symposium was witnessing the CyberDrill being fully designed and executed by young African cybersecurity talents. Watching these brilliant minds craft such a technically rich, high-impact defensive exercise filled me with pride. Their work wasn’t just impressive it was proof that Africa’s next generation of defenders is already here, already skilled, and already contributing meaningfully to the continent’s cybersecurity landscape.

I was excited to meet some of the young talents behind the CyberDrill, especially the exceptional minds from Benin, whose ingenuity and professionalism continue to raise the bar.

Seeing the CTF winners from Tanzania was another proud moment — especially because a woman was part of the winning team. Representation matters, and seeing her shine gave me so much hope for the future of women in cybersecurity.

During the conference, another CTF took place, and the ladies from Botswana delivered an outstanding performance, securing 3rd place. For me, that is a huge win not just for them, but for every young African woman who needs to see what is possible when passion meets opportunity.

The only part that truly broke my heart was not seeing any young people from Mauritius represented in the cybersecurity tracks or youth-focused activities. As the host nation, I had hoped to meet and celebrate local young talents too. I genuinely hope that in future editions, we see Mauritius’ emerging cybersecurity youth taking their rightful place on that stage because the continent needs every voice, every talent, and every young defender.

Wisdom from the Continent’s Cybersecurity Leaders

Mr. Abdul Hakeem Ajijola (AU Cybersecurity Expert Group)

“We cannot clap with one hand.”
Unity is non-negotiable.

Mr. Olivier Caleff (Chair, FIRST)

Collaboration across partners — and even competitors — is vital.

Mr. Jean-Robert Hountomey (Executive Director, AfricaCERT)

We are raising the next generation, and cybersecurity now requires a mindset shift toward trust.

Hon. Dr. Avinash Ramtohul (Minister, Mauritius)

We are no longer protecting computers; we are protecting society.

These words have stayed with me and continue to shape my perspective.

Gratitude, Growth, and a United Future

As AfricaCERT celebrates 15 years of impact and 10 years of partnerships, I am beyond proud to be part of this community. To the AfricaCERT Team, and to Mr. Jean-Robert Hountomey, a huge congratulations on the incredible growth, the influence, and the legacy you continue to build.

Thank you for believing in young people, for opening doors for us, and for trusting us to be part of Africa’s cybersecurity evolution.

I leave this Symposium with:

• deeper knowledge,
• stronger relationships,
• a sharper sense of responsibility, and
• a renewed commitment to contribute to Africa’s digital resilience.

And I carry with me three questions that will guide my future, shared by Mr. Abdul Hakeem Ajijola:

What did I do right?
What could I have done better?
And how can we improve?

This is how we grow.
This is how Africa grows.
And this is how the defenders unite.

Hope to attend another AfricaCERT symposium next… Do stay tuned and check out the AfricaCERT page on LinkedIn to check out the interviews Adeola and I got to do.

A Call to Organisations: Invest in Your People, Invest in Africa’s Cybersecurity Future

As I reflect on everything I learned at the AfricaCERT Symposium, one message becomes clear: no organisation can afford to overlook the importance of developing its cybersecurity talent. Events like the AfricaCERT Symposium are not just conferences they are hubs of innovation, collaboration, and shared progress. They are spaces where real strategies are born, where defenders unite, and where African excellence is amplified.

I strongly encourage organisations, government agencies, CSIRTs, private companies, educational institutions, and security teams to invest in their staff by enabling them to attend, participate in, and contribute to forums like AfricaCERT. The return on this investment is immeasurable:

Why organisations should invest in their cybersecurity teams:

1. Exposure to continental and global best practices
These events bring together the continent’s brightest minds and top experts. Your staff will gain insights impossible to get from textbooks or online courses.

2. Practical, hands-on training that builds real defensive capability
From ransomware investigations to OT security, to CSIRT maturity modelling — the skills gained can immediately be applied in your environment.

3. Access to AfricaCERT’s powerful professional network
Partnerships, intelligence-sharing, cross-border collaboration, and trust networks are built here. These relationships become critical during incidents.

4. Opportunities for professional growth and leadership
Staff who attend can take on leadership roles in projects, working groups, and training initiatives within the AfricaCERT community.

5. Strengthening your organisation’s cyber resilience
Investing in people means investing in stronger incident response, better security posture, and higher organisational maturity.

6. Visibility and recognition on a continental platform
Sponsors and collaborating organisations gain brand recognition, insights, and the opportunity to shape Africa’s cybersecurity landscape.

7. Empowering young talent and ensuring continuity
Africa’s future defenders are already emerging. Organisations must nurture them not only for their own benefit, but for the safety of our entire digital ecosystem.

AfricaCERT Has Built a Platform Worth Investing In

The sponsorship deck shared at the Symposium highlights clear pathways for organisations to partner with AfricaCERT whether as Visionary, Strategic, Supporting, Contributing, or Friend-level collaborators. Each tier offers valuable benefits such as:

• visibility on AfricaCERT’s platforms,
• leadership or participation in AfricaCERT projects,
• discounts to events,
• publication opportunities,
• access to the AfricaCERT General Meeting,
• insights into emerging regional and global cyber trends,
• joint initiatives with AfricaCERT members.

These are not just perks they are strategic assets for any organisation serious about cybersecurity.

Strengthening Africa Starts With Strengthening Your People

If we want a resilient digital Africa one capable of responding to threats, safeguarding critical infrastructure, and protecting our people then we must be intentional about investing in the defenders who will carry that responsibility.

I urge organisations to:

• fund their staff’s participation in AfricaCERT events,
• encourage youth involvement in CyberDrills and CTFs,
• sponsor emerging talents,
• contribute to AfricaCERT’s capacity-building initiatives,
• become long-term collaborators in building an African cybersecurity ecosystem rooted in excellence, unity, and knowledge-sharing.

A secure Africa will not be built by accident it will be built by those who invest in their people today.

AfricaCERT has created the platform.
The talent is here.
The future is waiting.

It is now up to organisations to step forward and play their part.

APIs have become the backbone of almost everything we use today, from mobile apps to backend services and even IoT devices in our homes. And because they connect straight to real data and business logic, they also happen to be one of the biggest targets for attackers. After completing the API Security Fundamentals course, I really wanted to take the theory off the slides and see what it looks like in real life. I wanted to understand how real APIs behave, where they can fail, and how those failures tie back to the OWASP API Top 10.

For this project, I worked with crAPI (Completely Ridiculous API) a purposely vulnerable API created by OWASP, and used Postman to explore different requests and responses. (You can also use Burp Suite if you prefer.) By deploying crAPI locally with Docker and interacting with its GET, POST, PUT, and DELETE endpoints, I got to see real security weaknesses up close and understand how attackers take advantage of them.

And just to be honest, getting crAPI up and running requires a lot of patience and troubleshooting. It’s not a “click once and it works” kind of setup. But if you stick with it, you’ll learn more than you expect. That’s what happened to me. Even through all the errors and retries, there was something worth learning, and I’m glad I pushed through. Now I get to share what I learned with you.

Anyway…here’s how I did everything, what I tested, what I found, and what stood out to me the most.

Goals:

• Deploy crAPI locally and interact with endpoints via Postman (or Burp).
• Observe API request/response behaviour and identify OWASP API Top 10 issues in practice. Understanding of the HTTP status response
• Document testing steps, findings, and quick mitigation ideas.

Tools & prerequisites

• Docker (running)
• Docker Compose (recommended >= 1.27.0; my system had 2.32.4-3)
• Postman (or Burp Suite)
• crAPI repo: https://github.com/OWASP/crAPI (clone this repo)

Installation / Setup (short, practical)

1. Update system and install curl:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl

1. (Optional) Install a specific Docker Compose binary (example for v1.27.0):

sudo curl -L "https://github.com/docker/compose/releases/download/1.27.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

1. Clone crAPI:

git clone https://github.com/OWASP/crAPI.git
cd crAPI

1. Edit docker-compose.yml as you need to change ports or settings (I adjusted crapi.web and mailhog).

1. Start with compatibility mode (example):

docker-compose -f docker-compose.yml --compatibility up -d

1. If something fails, you might need to delete containers and re-run:

docker-compose down
docker-compose up -d

Tip: you may see permission errors — try prefacing with sudo where needed. If you’re stuck, I copied error messages into an AI agent to troubleshoot work smart, not hard.

Open the dashboard in your browser (adjust port if you changed it):
http://localhost:8888/dashboard

How I tested (Postman workflow)

1. Create a Postman workspace/collection called crAPI.
2. Start with the signup endpoint (POST). Fill the JSON body to match what you see in the browser network inspector.

• Note: the signup form on the UI expects an American phone format in my test, so include a US-style number to avoid validation errors.

1. Inspect the browser Network tab while signing up, see the raw request and response.
2. Copy the login endpoint URL and create a POST request in Postman. Set the body to raw → JSON and paste the login payload (email, password).
3. Send the login request. Observe the JSON response tokens and other PII may be visible.
4. Use the returned token as a Bearer token in the Authorization header for protected endpoints (dashboard, vehicles, orders, etc.).
5. Test endpoints one-by-one:

• Dashboard (GET)
• Vehicle endpoints (GET/POST/PUT/DELETE)
• Orders (POST) and Returns (POST/PUT as applicable)
• Email change & email verification flows

This part of the project I did not show. If you are having difficulties understanding how to do it, do let me know in the comments so I can show it

What I observed (findings mapped to OWASP API issues)

Below are the key observations I made while testing crAPI.

BOLA — Broken Object Level Authorization (Top risk)

When looking at endpoints that return user data, I found scenarios that exposed another user’s PII by manipulating IDs or tokens (which I got to exploit with my own information). BOLA happens when the API returns or allows modification of objects without verifying that the logged-in user actually owns that object. Breach of confidentiality and integrity as well

Practical sign: I could inspect requests and see IDs and tokens in responses. If an attacker changes an object ID in a request and the server doesn’t validate ownership, they can access someone else’s data.

This one stood out the most.
If the API doesn’t check who actually owns a resource, attackers can just change object IDs and access someone else’s stuff.

While testing, I noticed how easy it would be to manipulate certain IDs. That’s exactly how BOLA attacks happen.

Login Endpoint on Postman

• Signup (POST): returns 200 and user object. The Network inspector shows the request payload and server response.
• Login (POST): returns token in JSON. In Postman, I set this token as Bearer token in Authorization.
• Dashboard (GET): returns the user’s name and other PII in the response body.

If these endpoints do not enforce strict access control checks, attackers with valid tokens or manipulated requests can access other users’ data.

Dashboard Endpoint

Once authenticated, I hit the dashboard GET endpoint. And wow, the API was honest. Too honest. It returned my name, email, and other personal details in full.

Here’s the real problem:
I tested how it would behave with missing or wrong tokens. Sometimes it gave 404, sometimes 401… and that inconsistency already tells you the authorization checks might not be tight.

But the biggest red flag?
It didn’t look like the API was doing strict “ownership” checks. Meaning if someone had a valid token and simply guessed another user’s ID (if IDs are predictable)… they could possibly pull someone else’s dashboard data.

That’s straight-up BOLA (Broken Object Level Authorization).

Vehicle Endpoint

Moving to the vehicle endpoints was eye-opening. These endpoints were basically showing everything internal IDs, ownership fields, metadata…

The scary part was when I tried modifying certain fields. At this point, I just sat back like
“So you’re telling me anyone with creativity and Postman can change who owns a car?” based on the information I am seeing

Yeah, that’s BOPLA at its finest.

Attacker thinking:

• Change ownership of a vehicle to themselves
• Modify states they shouldn’t be touching
• Enumerate other users’ vehicles by tweaking IDs

This is how real-world breaches happen.

Orders & Returns Endpoints

This section was a whole journey for me.

I tested the order endpoint first, and the API trusted everything I sent. Prices, quantities, order details… it didn’t recalculate anything on the server side. If I wanted to, I could literally set my total to 0.00 and get a free order.

Then came the return endpoint…
And I fought with this one. It kept throwing errors every time I tested it. I tried debugging with Postman, even threw it at AI for help. Still no luck.

But that struggle itself showed me that the API’s business logic wasn’t stable. “You can’t return an order that was never delivered”. Some APIs ignore this, and attackers exploit it.

This falls under: A06 — Unrestricted Access to Business Flows.

Attacker imagination:

Return someone else’s order

Trigger refunds repeatedly

Abuse the order creation flow to get free or discounted items

When the order and return logic isn’t protected, attackers don’t need to be hackers… they just need to be bold.

Eamil change and Verification of the Email change Endpoint

The email-change process was another point where I paused.

Changing your email is sensitive, it should require re-authentication, but this API was like:

“Sure, here’s your email change. Also here’s some extra info while you’re at it.”

The verification flow also revealed more data than I expected. In some cases, tokens or flags showed up in responses where they shouldn’t be.

Why this is dangerous:
Email = identity. If an attacker takes over your email, they can reset your password on almost everything.

Issues present:

• Broken Authentication
• BOPLA
• Sensitive Data Exposure

If verification tokens ever leak or are guessable, attackers can hijack accounts silently.

The Patterns I Kept Seeing (Across All Endpoints)

By the time I tested everything, a pattern became clear:

1. Too much PII in responses
2. Too many fields exposed in update requests
3. Tokens and IDs thrown around casually
4. Weak validation in multiple flows
5. Authorization checks not consistent or not enforced
6. Business logic that trusts the client way too much

In real attacks, hackers don’t always need fancy malware. They just look for one weak spot like this, and everything unravels.

Broken Authentication & Session Management

I found authentication flows that leaked credentials or tokens in responses. Weak or missing login controls let attackers take over accounts if tokens are exposed or predictable.

Practical sign: login responses revealed an auth token in the JSON body — if tokens aren’t protected or rotated properly, they can be abused.

BOPLA — Broken Object Property Level Authorization

Some endpoints allowed updating fields that shouldn’t be modifiable (e.g., changing someone else’s role, ID, or PII fields). APIs that expose more fields than necessary are easier to exploit.

Practical sign: over-permissive update endpoints and responses showing internal IDs and tokens.

Unrestricted Access to Business Flows (OWASP A06)

Attackers can abuse business logic flows (e.g., order creation + return flow) to get unauthorized benefits or to discover more system behavior and data.

Practical sign: by following the API workflow and observing every response stage, you can see where the business flow lacks checks and can be abused.

General PII exposure

Multiple endpoints leaked personal data (email, full name, phone number), which could be aggregated and sold. Even if each leak seems minor, combined they form a big risk.

What I Learned in Summary

Doing this project taught me that APIs can look functional on the surface but be wide open underneath.

If you don’t test the endpoints deeply not just “does it return 200?” but “does it return EXCESS?” you’ll miss the things attackers never overlook.

This project honestly made the OWASP API Top 10 make more sense.
Seeing BOLA, BOPLA, Broken Auth, and Excessive Data Exposure happening live, in front of me, hit way harder than just reading the names in a course.

I hope you found this informative and that you picked up something valuable along the way, because I’m also learning as I go. Let’s walk this journey together. As I dive deeper into real-world vulnerabilities and how they’re exploited, I’ll keep breaking things down and showing you how we can defend against them from an API security point of view. More to come and we grow together.

Don't forget to read the Understanding API Security: Lessons from the API Security Fundamentals Course

I appreciate feedback as it allows me to grow and know I can improve further. If you enjoyed and found this valuable, don’t forget to clap and comment. Thank you

During the API Security Fundamentals course, one thing that really hit me is how exposed and risky APIs can be if they aren’t designed and managed properly. APIs are everywhere in modern systems, and because they usually connect straight to real data and business functionality, attackers see them as a direct way in. That’s why learning API security is so important — it helps reduce the chance of data breaches, protects users and the business, and ensures compliance with security standards.

Before even looking for vulnerabilities, it’s crucial to understand how APIs actually work. This starts with threat modeling, which is basically identifying all the APIs in your environment, how they interact with data, and what business purpose they serve. Something I found interesting is that API discovery is part of security, you can’t protect what you don’t know exists, including older versions or internal APIs that might still be running.

I also learned a lot about governance, which is having rules and guidelines so APIs are built securely and consistently from the start. This includes proper API specifications, style guides, and keeping an updated inventory of all APIs. Without this, it’s easy for forgotten APIs to be exploited later.

Then came the discussion on vulnerabilities, focusing on the OWASP API Security Top 10. Here’s how I understood them:

• BOLA (Broken Object Level Authorization): Someone can access another person’s data by tweaking an ID.
• Broken Authentication: Weak or missing login controls allow attackers to break in.
• BOPLA (Broken Object Property Level Authorization): APIs expose more data than needed or allow updates to fields that shouldn’t be changed.
• Unrestricted Resource Consumption: No limits or controls can lead to DoS attacks or data scraping.
• Broken Function Level Authorization: Normal users can access admin-only functions.
• Unrestricted Access to Business Flows: Attackers exploit the intended workflow of the system.
• SSRF (Server-Side Request Forgery): Attackers trick the API into sending requests to internal systems.
• Security Misconfiguration: Misconfigured servers, unused features, or error messages that leak info.
• Improper Inventory Management: Unknown or outdated APIs running without monitoring.

The course highlighted three pillars for API security: Governance, Testing, and Monitoring. Security isn’t something you check once; you need rules, thorough testing (not just automated scans), and continuous monitoring to catch suspicious activity early.

Next, we looked at the application security technology landscape. The market for cybersecurity tools is huge, and for APIs, this is a key point: traditional tools like SAST and DAST are great for common vulnerabilities, but APIs rarely get breached through those. Attackers are after unique logic flaws, gaps in authorization, or ways to abuse API functions. Standard scanners often miss these, so APIs need deeper, customized testing.

The course walked through the API lifecycle and where security should be applied:

1. API Definition Phase: Design the API with security in mind. Ask what data it accesses, potential risks, and required controls.
2. Development Phase: Code reviews, static analysis, and composition checks are critical, especially for spotting logic flaws.
3. Testing Phase: Before going live, run manual and automated API-specific security tests, penetration testing, and simulate attacks.
4. Runtime Phase: Firewalls, API gateways, and SIEMs help detect and block attacks in real-time.
5. Decommissioning: Retire old APIs properly to avoid leaving vulnerabilities exposed.

Mapping risks to the lifecycle is important. For example: unknown APIs can be tracked with a gateway or runtime detection; unauthorized access can be handled during coding with proper controls or during testing by simulating scenarios. The goal is a prioritized list of risks and where to mitigate them, ideally as early as possible.

Finally, the course wrapped up with common API risks and best practices. Common issues organizations face include:

• API Discovery: Hard to manage all endpoints, including shadow or rogue APIs.
• Vulnerable APIs: Flaws in development or configuration can lead to breaches.
• Weak Runtime Defenses: Tools like firewalls are useful but not a magic fix.
• Third-Party APIs: Must know how external APIs are being used.
• Weak Governance: Without strict policies, APIs can be inconsistent and risky.
• Poor Collaboration: Security and development teams must work together; many API flaws require engineering involvement to fix.

The course also gave a practical Top 10 Do’s and Don’ts for API security:

• Don’t trust anything: Always assume input could be malicious.
• Validate all inputs: Only accept what’s expected; reject everything else.
• Don’t reveal sensitive info in errors: Give users enough info, but don’t help attackers.
• Expect API discovery: Even undocumented APIs can be found.
• Don’t have hidden features: Unadvertised endpoints are a risk.
• Don’t filter data in the UI: Enforcement should happen in the application.
• Use an API gateway: Centralize management, control access, and monitor usage.
• Don’t confuse authentication and authorization: Authentication proves identity; authorization controls what they can do.
• Require proper API documentation: Keep it updated for internal and external users — it’s also a security tool.
• Do continuous testing: Simulate attacks and check for logic flaws, authorization gaps, and unsecured endpoints with every release.

The key takeaway is that API security is ongoing. By discovering all APIs, building governance and collaboration, and continuously testing, organizations can significantly reduce risks and keep their APIs safe.

By learning about API Security, it is also important to understand HTTP Response Status Codes:
HTTP response status codes tell you how a server handled a request. They are essential in API security and development because they help you:

1. Diagnose issues quickly — 404 means a resource isn’t found, 500 indicates a server error.
2. Handle responses correctly in applications — knowing if a request succeeded (200) or was unauthorized (401) allows your app to respond appropriately.
3. Prevent security issues — improper handling of status codes can leak sensitive information or allow attackers to infer system behavior.
4. Aid in testing and debugging APIs — especially when using tools like Postman or cURL, you can verify if your API behaves as expected under different scenarios.

In short, understanding status codes helps developers and security teams ensure APIs are robust, secure, and predictable.

Next is the Project demonstrating all this. Stay tuned, you will love it.

What if a few keystrokes in a login box could expose your entire database?

In a recent hands-on lab, I explored just how devastating SQL Injection can be — by walking through a real attack, packet by packet, using Wireshark. What started as a simple 1=1 turned into full database exfiltration… including usernames and hashed passwords.

This wasn’t just theory. This was practical, forensic cybersecurity training — and a sobering look at how small coding mistakes can lead to big breaches.

The Setup: A Hacker’s Playground

We were given a .pcap file—a packet capture from a previous attack on a MySQL database. The challenge? Open it in Wireshark and retrace every step the attacker took.

Spoiler: They didn’t just break in…
They toured the database, stole credentials, and walked out unnoticed.

The Attack Begins: One Tiny Query

It all starts with something deceptively simple:

1=1

The attacker injects this into a login field and sends it via HTTP GET. If the app responds with user data rather than an error, bingo: it’s vulnerable to SQL injection.

In Wireshark, this looks like:

GET /vulnerableapp?userid=1%3D1 HTTP/1.1

Wireshark lets us follow the HTTP stream — and sure enough, the server replies with valid data. The attacker now knows: input is being executed as SQL.

Target Locked: Extracting Metadata

Next comes enumeration.

Using:

1' or 1=1 union select database(), user()#

…the attacker cleverly asks the database to tell him its name and which account is being used. The result?

• Database: dvwa
• User: root@localhost

This isn’t guesswork — this is precision. The attacker is using built-in SQL functions (database(), user()) to learn about the environment.

Getting Technical: System Version

What’s better than knowing your target? Knowing exactly which version of MySQL it’s running. That’s what the following query does:

1’ or 1=1 union select null, version()#

With the version ID, an attacker can pivot to version-specific exploits — making the breach deeper, faster, and potentially persistent.

Blueprint of the Castle: Table Mapping

Still using the same injection point, the attacker now explores the entire database structure:

1’or 1=1 union select null, table_name from information_schema.tables#

This tells them what tables exist in the database. One word: users.

Next up:

1' OR 1=1 UNION SELECT null, column_name FROM INFORMATION_SCHEMA.columns WHERE table_name='users'

And now they know every column inside the users table—probably including username and password.

The Kill Shot: Password Extraction

Finally, they go straight for the goods:

1’or 1=1 union select user, password from users#

In seconds, the attacker has usernames and password hashes. No brute-forcing needed. Just poorly written code and unrestricted input.

Using a tool like CrackStation, these hashes can be cracked in seconds if they’re weak — like this one:

8d3533d75ae2c3966d7e0d4fcc69216b → password

Yes. That was the password. Just… “password”.

What I Learned (and Why You Should Care)

This lab taught me that:

• Attacks don’t need malware — they just need poor code.
• Packet captures are forensic gold for defenders.
• A few well-placed SQL functions can reveal everything.
• Hashing alone isn’t enough — passwords still need to be strong and salted.

Defending Against SQL Injection

Here’s how we can stop this:

1. Use Prepared Statements
   Never build queries with string concatenation.
2. Validate and Sanitize Input
   Don’t trust anything from a user — ever.
3. Limit DB Permissions
   The web app shouldn’t use a root database account. Ever.
4. Deploy WAFs and Monitoring
   Detect patterns like 1=1, union select, etc.

Want to Try This Yourself?

I built a full GitHub project from this lab:

🔗 (https://github.com/CoderBlee/CyberOperation/tree/main/sql-injection-wireshark-analysis)

It includes:

• Full technical breakdown
• Annotated screenshots
• Cracked hashes
• Prevention guide
• Reflection journal

Conclusion

SQL injection may seem “old school,” but it’s still one of the most common and dangerous vulnerabilities out there. If your inputs aren’t sanitized, your data isn’t safe.

I walked through this attack with Wireshark. Next time, I’ll use that knowledge to stop one.

Thanks for reading
Let me know if you’ve done similar labs or want to collaborate on more cybersecurity experiments.

#Cybersecurity #SQLInjection #Wireshark #Infosec #WebSecurity #EthicalHacking #BlueTeam #CaptureTheFlag #CTF #Forensics #BugBounty #OWASP

Introduction

In this comprehensive lab project, I used Wireshark and tcpdump tools to analyze multiple types of network traffic on the CyberOps Workstation VM. The goal of this project was to understand how common protocols such as DNS, FTP, TFTP, HTTP, and HTTPS work at the packet level, and to examine the security implications of each protocol in real-world use. Each section of the project is structured with commands I ran, what I observed, and detailed explanations of why each step matters.

Part 1: DNS Capture and Analysis Using UDP

Step 1: Record IP Configuration Information

I began by verifying the network configuration of my virtual machine. I needed to collect the MAC address, IP address, DNS server, and default gateway.

ifconfig

This displayed interface information. My interface was enp0s3, which showed my IP address and MAC address.

cat /etc/resolv.conf

This command listed the DNS servers configured for my system.

netstat -rn

This helped identify my default gateway IP address.

Why This Matters:
Understanding the IP configuration is foundational to analyzing packets. When filtering traffic later, I needed to know which IP was mine and which were remote.

Security Note:
DNS queries are often unencrypted. This means an attacker on the same network can potentially capture the sites I visit by sniffing DNS traffic.

Step 2: Capture DNS Queries and Responses

I launched Wireshark using the command below:

wireshark &

Then I selected the interface enp0s3 and clicked Start. I opened a web browser and navigated to www.google.com.

Once the page loaded, I stopped the capture.

Step 3: Analyze the Packets

I applied the filter:

dns

I looked for a packet showing a standard DNS query (A www.google.com) and its response.

Why This Matters:
This helped me understand how DNS uses UDP (connectionless) to resolve domain names. DNS queries use port 53.

Security Note:
Since UDP does not guarantee delivery, applications must handle retries. Also, DNS is often exploited in DDoS attacks and data exfiltration.

Part 2: Analyze TCP and UDP Captures (FTP and TFTP)

Part 2.1: Analyze TCP Traffic via FTP

Step 1: Start Wireshark

wireshark &

I selected enp0s3 and clicked Start.

Step 2: Start FTP Session

In another terminal, I connected to the CDC’s FTP server:

ftp ftp.cdc.gov

Login credentials:

Name: anonymous
Password: [press Enter]

Step 3: Download File

ls
get Readme
quit

Step 4: Apply Wireshark Filter

In Wireshark:

tcp and ip.addr == 198.246.117.106

Why This Matters:
This part demonstrated TCP’s reliability through SYN, ACK, FIN flags, and sequence numbers. I saw how a session is established and torn down.

Security Note:
FTP transmits data and credentials in plain text. Sensitive data can be stolen if used over insecure networks.

Part 2.2: Analyze TFTP via UDP (Mininet)

Step 1: Start Mininet and Terminals

sudo lab.support.files/scripts/cyberops_topo.py
mininet> xterm H1 H2

Step 2: Start TFTP Server and Prepare Files

On H1:

/home/analyst/lab.support.files/scripts/start_tftpd.sh
echo "This file contains my tftp data." > /srv/tftp/my_tftp_data

On H2:

touch my_tftp_data

Step 3: Capture and Perform TFTP Transfer

On H1:

wireshark &

Select interface: H1-eth0

From H2:

tftp 10.0.0.11 -c get my_tftp_data

Filter in Wireshark:

tftp

Why This Matters:
This highlighted how UDP handles file transfers without session management. I saw how port numbers change dynamically.

Security Note:
TFTP is insecure by design. No authentication, no encryption. Only use it in trusted networks.

Part 3: Analyze HTTP and HTTPS Traffic

Part 3.1: HTTP Capture

Step 1: Start tcpdump to Capture HTTP

sudo tcpdump -i enp0s3 -s 0 -w httpdump.pcap

Step 2: Open Browser

Visited:

http://www.altoromutual.com/login.jsp

Login credentials:

Username: Admin
Password: Admin

Stopped capture with CTRL+C.

Step 3: Analyze in Wireshark

Opened httpdump.pcap and filtered:

http

Looked for POST requests and decoded form data under HTML Form URL Encoded.

Why This Matters:
I clearly saw the login credentials sent in plain text. HTTP offers no confidentiality.

Security Note:
NEVER log into a website over HTTP. Use HTTPS to protect data.

Part 3.2: HTTPS Capture

Step 1: Start tcpdump

sudo tcpdump -i enp0s3 -s 0 -w httpsdump.pcap

Visited:

https://www.netacad.com

Logged in with dummy credentials.

Stopped capture with CTRL+C.

Step 2: Analyze in Wireshark

Filtered by:

tcp.port == 443

Looked for TLS Application Data.

Why This Matters:
Even though the packets were visible, the contents were encrypted and unreadable.

Security Note:
HTTPS provides encryption, authentication, and data integrity. However, not all HTTPS sites are safe (phishing sites also use HTTPS).

Reflection Questions and Summary

Why is HTTPS better than HTTP?

Because it encrypts all traffic and protects credentials from eavesdropping. It also authenticates servers via certificates.

Is every HTTPS site safe?

No. Encryption doesn’t equal trustworthiness. Some attackers use HTTPS for phishing.

How is TCP different from UDP?

TCP ensures reliable, ordered delivery with error checking. UDP is faster but doesn’t guarantee delivery or order.

Final Thoughts

This lab gave me valuable hands-on experience with real network traffic. I learned not only how protocols function but also how to examine their strengths and vulnerabilities. I now understand why encrypted, authenticated traffic is critical in today’s cyber landscape

Please go Like, Comment and Subscribe. Thank you for your Support