The API Vulnerabilities I Keep Finding in Web App Pen Tests (With Step-By-Step Testing)

Modern web applications depend heavily on backend APIs, yet these APIs are often the least tested and most vulnerable part of the attack surface. As a penetration tester, these are the API flaws I repeatedly find during real client engagements. Each example below includes the actual requests, responses, and exploitation methodology used to validate the vulnerability.

These issues don’t require fancy zero-days. They’re almost always logic flaws, access control gaps, and unsafe defaults. And they lead to real security problems:

• Sensitive data exposure

• Account takeover

• Unauthorized access

• Internal network pivoting

• Credential bypasses

Below are the five API vulnerabilities I most commonly find in real-world client engagements, along with the exact steps I use to test for them.

---

1. Excessive Data Exposure

APIs often return much more data than the frontend actually needs. Developers assume the app will “hide” fields, but the API response still contains:

• Full user objects

• Emails

• Metadata

• Internal IDs

• Role flags

• Vehicle IDs, account IDs, etc.

This is one of the easiest ways attackers gather pivot points for deeper exploitation (like IDOR).

How I test it

1. Use the app normally while proxying traffic through Burp Suite.

2. Capture any API call returning lists or profile data.

3. Send the request to Repeater.

4. Compare what the UI displays vs. what the API actually returns.

5. Mark anything “invisible to UI but present in JSON” as excessive exposure.

Why it matters

Exposed IDs often become the foothold for IDOR, account takeover, or SSRF chaining.

---

2. IDOR / BOLA (Broken Object Level Authorization)

This is easily the #1 most common API vulnerability I find.

When APIs trust user-supplied identifiers (like userId, vehicleId, orderId), attackers can simply change the ID to access other users’ data.

How I test it

1. Find any API request referencing an ID.

2. Send the request to Burp Repeater.

3. Modify the ID (e.g., 103 → 104).

4. Send the request.

5. If I see someone else’s data, it’s a confirmed IDOR.

Why it matters

IDOR often leads to:

• Viewing other users’ profiles

• Viewing private location data

• Downloading other users’ invoices

• Seeing internal reports or documents

These are high-severity findings in real engagements.

---

3. SSRF (Server-Side Request Forgery)

SSRF appears when an API allows users to supply a URL — and the server fetches it.

That means you can trick the backend into making requests to:

• Your controlled server (to confirm SSRF)

• Internal network resources

• Cloud metadata endpoints

How I test it

1. Look for URL parameters (callbackUrl, imageUrl, apiEndpoint, etc.).

2. Replace the URL with a Burp Collaborator link.

3. Send the request.

4. Wait for DNS/HTTP callbacks in Collaborator.

5. If allowed by scope, test internal targets like:

   • http://127.0.0.1

   • http://169.254.169.254 (cloud metadata)

Why it matters

SSRF is often a pivot point into:

• Internal admin dashboards

• Redis/memcached

• AWS/Azure metadata (temporary credentials)

• Internal APIs

It’s one of the highest-impact API vulnerabilities.

---

4. NoSQL Injection

APIs backed by MongoDB or other NoSQL engines often fail to validate JSON input. Attackers can inject operator objects such as:

{"$ne": 1}

This can bypass validation, fetch unintended data, or manipulate backend queries.

How I test it

1. Identify JSON-based lookup endpoints (coupon validation, search APIs, etc.).

2. Replace the value with an operator object:

   {"$ne": 1}
   

3. Send the request.

4. If the API behaves differently (e.g., coupon accepted), it’s vulnerable.

Why it matters

NoSQLi can reveal:

• Internal records

• Private coupons

• User lists

• Administrative objects

In some cases, it leads to full database access.

---

5. Broken Authentication

Some APIs don’t actually validate authentication tokens. They accept:

• Removed Authorization headers

• Expired tokens

• Invalid JWTs

• Or no token at all

This happens more than you’d think, especially when JWT validation is misconfigured.

How I test it

1. Capture an authenticated API request.

2. Send it to Burp Repeater.

3. Remove the Authorization header entirely.

4. Replace the token with garbage (abc123).

5. Resend and observe whether the API still returns sensitive data.

Why it matters

Broken authentication allows:

• Account takeover

• Access to private data

• Role escalation

• Data scraping

• Unauthenticated internal actions

This is almost always rated Critical.

---

Final Thoughts

These five vulnerabilities show up again and again across real production APIs. And most of them have nothing to do with complex exploits they’re caused by:

• Missing authorization checks

• Overly permissive responses

• Blindly trusting user input

• Inconsistent validation

• Legacy endpoints still in production

If you’re building APIs, these should be part of your core threat model.

If you’re pentesting APIs, this is your core attack playbook.

Red Team Simulation: Active Directory Pentest

 

Introduction

In this project, I conducted a full-scope Active Directory penetration test against a simulated enterprise environment to emulate a real-world attacker. The objective was to identify and exploit common AD misconfigurations, privilege escalation paths, and authentication flaws that could lead to full domain compromise.

Read the report here

Assessment Overview

The penetration test simulated an attacker who gains initial access to an internal Windows workstation. From there, I used various techniques to pivot through the network and escalate privileges within the domain.

Key techniques used:

• Credential dumping via Mimikatz

• Pass-the-Hash (PTH) and Kerberoasting

• AS-REP roasting

• Abuse of DCSync rights

• Golden Ticket attack using compromised krbtgt hash

---

Key Attack Paths Discovered

1. Credential Dumping + Pass-the-Hash

After gaining local admin on a Windows 10 machine, I used Mimikatz to dump hashes and perform a Pass-the-Hash attack to impersonate a Domain Admin.

Recommendation: Implement Local Admin Password Solution (LAPS) and disable unnecessary local admin access.

---

2. AS-REP Roasting

I identified user accounts with "Do not require Kerberos pre-authentication" enabled. This allowed me to request and crack AS-REP hashes to retrieve plaintext passwords.

Recommendation: Disable the pre-auth exemption using PowerShell:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True}

---

3. Kerberoasting

Using a standard domain user, I requested service tickets (TGS) for SPNs and cracked the hashes offline using John the Ripper with rockyou.txt.

Recommendation: Use strong, randomly generated passwords for service accounts, especially those tied to SPNs.

---

4. Golden Ticket Attack

With the krbtgt hash obtained via DCSync, I generated a forged TGT (Golden Ticket) and authenticated to the domain controller as any user.

Recommendation: Reset the krbtgt account twice and monitor for unusual Kerberos activity via event logs.

---

Tools Used

• Mimikatz

• Impacket

• BloodHound

• Responder

• John the Ripper

• CrackMapExec

• SharpHound

• hashcat

---

What I Learned

This project sharpened my hands-on skills in Active Directory exploitation, including lateral movement, persistence, and credential-based attacks. I also learned how to document attack chains, map BloodHound paths, and provide actionable remediation steps.

---

Conclusion

This AD penetration test highlights how common misconfigurations—like weak service account passwords or overly permissive ACLs—can be chained to compromise an entire domain. By addressing these gaps, organizations can significantly reduce their exposure to internal threats.

Azure Cloud Detection Lab

 

Azure Cloud Detection Lab

I had lots of fun with this one! In this project I configured and analyzed Azure resources to detect and respond to security threats effectively. Below is a streamlined overview of the project, covering setup, configuration, and key learnings.

Project Setup and Configuration
Step 1: Configuring and Deploying Azure Resources

• Log Analytics Workspace: Established as the core of data collection, set up to gather, query, and analyze log data from both Azure resources and external sources.

• Virtual Machines: Deployed within Azure to simulate an operational environment, meticulously configured with network settings and bolstered security against common threats.

• Azure Sentinel: Seamlessly integrated with the Log Analytics Workspace to provide cloud-native security analytics and intelligent threat intelligence.

Step 2: Implementing Security Best Practices

• Network Security Groups (NSGs): Configured to control both inbound and outbound VM traffic, allowing only authorized traffic.
• Virtual Machine Security: Applied security policies include enabling encryption and automatic updates to enhance VM security.

Step 3: Utilizing Data Connectors

• Essential for bringing data into Azure Sentinel for analysis, I explored various connectors to integrate diverse log sources like Windows Security Event logs and Azure Activity logs.

Step 4: Understanding Windows Security Event Logs

• I RDP'd into the VM. Once I did, I opened windows event view. I looked at event types and interpretations vital for monitoring and detecting unauthorized access and policy violations. Here I looked at events 4624 and 4672
  
  
  
  
  
  

In Azure we can see the events come up

Step 5: Configuring Windows Security Policies

• Configured settings related to account policies, audit policies, and advanced security options to ensure VMs meet security standards.

Step 6: Utilizing KQL for Log Queries

• Used Kusto Query Language (KQL) to write queries that identify patterns, anomalies, and potential security threats within the data. Now when we check the log queries we can see EventID 4624 come up.
  
  
  
  
  
  

Step 7: Writing Custom Analytic Rules

• Developed rules in Azure Sentinel to detect specific Microsoft security events, using KQL to trigger alerts under certain conditions.
  
  
  
  
  

Step 8: Mapping with MITRE ATT&CK

• I then applied the MITRE ATT&CK framework to map detected events to known adversary behaviors, aiding in threat context understanding and mitigation strategy development. And once we set everything you can see it up pop in the incidents tab(last screenshot below)
  
  
  
  
  
  
  
  
  
  
  
  
  

Conclusion

This project let me configure essential Azure resources and apply security principles for cloud security. And this is the tip of the iceberg for cloud security. 

Network Penetration Test Project Summary

Introduction

For this project I conducted a network penetration test for Example Corpo to evaluate their internal security posture. The assessment was carried out over a period of twelve days and focused on identifying and exploiting vulnerabilities within their network. Click here to view: Pen Test Report Project

Assessment Overview

The penetration test aimed to simulate the actions of an attacker within the internal network. This involved scanning for vulnerabilities, exploiting identified weaknesses, and assessing the impact of potential attacks. The key phases of the test included planning, discovery, attack, and reporting.

Key Findings

During the assessment, several critical and high-severity vulnerabilities were identified:

1. vsftpd 2.3.4 Backdoor (Critical)

   • An FTP server running vsftpd version 2.3.4 was found with a backdoor vulnerability. This allowed unauthorized access to the system.

2. FTP Weak Passwords (Critical)

   • Weak passwords were identified on the FTP server, making it susceptible to brute-force attacks. Using a tool called Hydra, the username "msfadmin" and its weak password were discovered.

3. SMB Vulnerabilities (Critical)

   • The EternalBlue exploit was used to gain a reverse shell, providing unauthorized access to the system.

4. WebDAV Misconfiguration (Critical)

   • The WebDAV service allowed unauthorized file uploads, enabling the upload of a PHP web shell that could execute commands remotely.

5. SMTP User Enumeration (High)

   • The SMTP server was vulnerable to user enumeration via the VRFY command, allowing attackers to verify valid usernames for further attacks.

Recommendations

To mitigate these vulnerabilities, the following actions were recommended:

1. Upgrade vsftpd

   • Upgrade to the latest version and restrict access to trusted users. Regularly monitor server logs for suspicious activity.

2. Enforce Strong Password Policies

   • Implement complex password requirements and account lockout mechanisms. Regularly review access logs for suspicious login attempts.

3. Patch and Update Systems

   • Update and patch all systems, disable SMBv1, and use SMBv2 or SMBv3. Implement network segmentation and monitor SMB traffic.

4. Secure WebDAV

   • Disable WebDAV if not needed, or restrict access to trusted IPs and require authentication. Conduct regular security audits.

5. Harden SMTP

   • Disable the VRFY command, use secure authentication methods, and implement rate limiting. Regularly monitor and audit SMTP logs.

Conclusion

The penetration test provided valuable insights into Example Corpo's internal security posture, identifying critical areas for improvement. By addressing the identified vulnerabilities and implementing the recommended security measures, Example Corpo can significantly enhance their security posture and reduce the risk of successful attacks. Regular security assessments and updates are crucial to maintaining a robust defense against evolving threats.

 

Why I Think the SOC Level 1 Learning Path on TryHackMe is Perfect for Beginners

Introduction

Some time last year (mid-2023), I was looking for the right training that would suit someone who was a little novice. I had some experience already. I heard a lot about TryHackMe and decided to check it out. The first path I did was SOC Level 1.

Accessible Learning Material

The SOC Level 1 learning path on TryHackMe is designed for beginners with virtually no experience. I had some certs and hands-on experience already, but I still found this challenging enough to where I had to think and problem-solve. The material is digestible and presented clearly to someone who isn't technical at all. Cybersecurity can get pretty complex, but this path took those complex topics and really broke them down Barney style.

Hands-On Experience

As someone who's very hands-on and visual, I really liked the labs. As a beginner, practical experience is invaluable. The SOC Level 1 path includes several interactive labs that allow you to apply what you’ve learned in real-world scenarios. These exercises cover:

• Investigating Security Incidents: Using tools like Splunk and Carbon Black to analyze and respond to simulated security incidents.
• Detecting Threats: Setting up and configuring SIEM tools to detect and investigate potential threats.
• Remediating Vulnerabilities: Performing vulnerability scans and applying patches to secure systems.

Structured Learning Path

For beginners, having a structured learning path is essential. The SOC Level 1 path is well-organized, guiding you step-by-step through the fundamentals of working in a SOC. The learning path covers key areas such as:

• Incident Response: Understanding the process of identifying, containing, eradicating, and recovering from security incidents.
• Threat Detection: Learning to detect potential threats using log analysis, network monitoring, and endpoint security.
• Vulnerability Management: Gaining skills in regular scanning, patch management, and maintaining secure configurations.

Real-World Relevance

The hands-on labs include real-world scenarios you would encounter as a SOC Analyst. The hands-on experience offers a lot of value. As a beginner, you can showcase this to employers during an interview. Even though you have no formal experience, it doesn't mean you can't demonstrate informal experience and enthusiasm to learn.

Community and Support

If you are struggling with these paths, Google will become your best friend if it already wasn't. Even better, some YouTubers have posted step-by-step tutorials, so you can easily have a split screen monitor and follow along.

Conclusion

The SOC Level 1 learning path on TryHackMe is an excellent starting point for beginners in cybersecurity. It offers accessible learning material, hands-on experience, a structured learning path, and real-world relevance. By completing this path, you’ll gain foundational skills and practical knowledge essential for a career in cybersecurity.

If you’re a beginner looking to break into the field, I highly recommend the SOC Level 1 learning path on TryHackMe. It’s a great way to build your skills, gain confidence, and prepare for the exciting challenges of a cybersecurity career.

Linux Privilege Escalation Project Summary

What is privilege escalation? 

Privilege escalation on a Linux machine involves exploiting vulnerabilities to gain higher access levels, such as root privileges. This is dangerous because it allows hackers to gain complete control over the system. Users should have proper security measures in place to prevent such exploits.

In this project, I demonstrated Linux privilege escalation by using LinEnum to gain root access and exploit hidden files. Here’s a step-by-step summary:

Step 1: Setting Up the Environment

I set up a target Linux machine and ensured I had SSH access. This allowed me to interact with the machine remotely.

Step 2: Running LinEnum

I downloaded and ran LinEnum, a script that helps in enumerating information and potential vulnerabilities in Linux systems. The command used was:

wget https://raw.githubusercontent.com/rebootuser/LinEnum/master/LinEnum.sh
chmod +x LinEnum.sh
./LinEnum.sh

Step 3: Analyzing the Output

LinEnum provided a detailed report on system configurations, potential vulnerabilities, and misconfigurations. I focused on areas with high privilege escalation potential.

Step 4: Identifying Hidden Files

During the analysis, I found hidden files and directories that were not secured properly. These files contained sensitive information that could be leveraged for escalation.

Step 5: Exploiting Vulnerabilities

I used the information from LinEnum to exploit identified vulnerabilities. For instance, I found a misconfigured sudoers file that allowed me to execute commands as the root user without a password:

sudo -i

Step 6: Gaining Root Access

By exploiting the sudoers file, I successfully escalated my privileges to root, gaining full control over the system.

Step 7: Documenting Findings

I documented all findings and steps taken during the project. This included the initial setup, execution of LinEnum, analysis of its output, exploitation of vulnerabilities, and the final privilege escalation.

Conclusion

This project highlighted the importance of regular system audits and proper configuration management to prevent privilege escalation. Using tools like LinEnum can significantly aid in identifying potential security weaknesses.