During a white-box security assessment of an IoT remote monitoring platform, I discovered a lack of authorization vulnerability that allowed an attacker to delete any user account, including administrator accounts, without authentication.

This write-up explains how the issue was discovered and how it could be exploited.

Target Overview

The tested application (referred to as example-portal.com) is a remote monitoring system for IoT devices.

The platform supports multiple user roles. Administrators can:

  • Create users
  • Modify users
  • Delete users
  • Define custom roles with specific permissions

For testing purposes, I used two accounts:

  • An admin account
  • A normal user account

The goal was to examine how the application handled authorization controls for sensitive actions.

Step 1 — Observing the User Deletion Request

While logged in as an administrator, I intercepted application traffic with Burp Suite and performed normal administrative actions.

When deleting a user from the admin dashboard, the application triggered the following request:

GET https://example-portal.com/system/api/system/user/delete?id=1013

Key observations:

  • The endpoint uses a GET request to delete a user.
  • The user identifier is passed as a parameter:
id=1013
  • User IDs appear sequential and guessable (e.g., 1013, 1014, 1015).

This raised an immediate red flag.

Step 2 — Testing Authorization Controls

To verify whether the endpoint enforced proper access control, I performed the following test:

  1. Created a new normal user account.
  2. Logged in using the normal user account.
  3. Directly visited the deletion endpoint in the browser:
https://example-portal.com/system/api/system/user/delete?id=1014

The page returned no visible response.

However, when I checked the admin dashboard, the user account with ID 1014 had been deleted successfully.

This confirmed that normal users could delete accounts without admin privileges.

Step 3 — Checking Authentication Requirements

Next, I inspected the request in Burp Suite.

Surprisingly:

  • The request did not include any authorization header like cookie=blahblah
  • There was no authentication token
  • No session validation was required

To confirm this behavior, I opened a private/incognito browser window and sent the same request without logging in.

https://example-portal.com/system/api/system/user/delete?id=1015

Result:

✅ The user account was deleted again.

Root Cause

The /system/api/system/user/delete endpoint lacked both:

  • Authentication checks
  • Authorization checks

As a result:

  • Anyone on the internet could access the endpoint.
  • Attackers could delete any user account simply by guessing the user ID.

Impact

This vulnerability allows an attacker to:

  • Delete any user account
  • Delete administrator accounts
  • Completely disrupt platform operations

User IDs are sequential and predictable, an attacker could automate requests and remove all users from the system.

Severity

High / Critical

Since no authentication, authorization are required and it can direct access to sensitive administrative functionality, it should be high or critical.

Recommended Fix

To prevent this vulnerability:

  1. Require authentication for all administrative endpoints.
  2. Implement server-side authorization checks to ensure only administrators can delete users.
  3. Avoid using GET requests for destructive actions; use POST or DELETE with proper validation.
  4. Implement non-predictable identifiers (UUIDs) instead of sequential IDs.
  5. Add logging and monitoring for account deletion actions.

Conclusion

This issue highlights a common but serious security problem: missing authorization checks on sensitive API endpoints.

Even though the application had a role-based system, the backend API failed to enforce those permissions. As a result, a simple crafted request could delete any account on the platform.

Always ensure that authentication and authorization are enforced on the server side, regardless of how the frontend behaves.