How a Public Token Led to Unauthenticated Read and Write Access on an IoT Platform

Summary

During authorized security testing of an IoT management platform, I identified a critical broken access control issue affecting multiple API endpoints.

The application exposed a public token on the login page. This token was obtainable without logging in. When reused against internal API routes, several endpoints processed the requests even though no authenticated session existed.

The issue allowed unauthenticated access to sensitive IoT inventory data, including device, group, and location information. More critically, certain state-changing endpoints accepted unauthenticated requests and performed real database updates.

The write impact was confirmed by checking a field value before and after the request. The value changed successfully, and the update timestamp also changed, proving that the backend executed a real database write rather than returning a fake success response.

The finding was reported responsibly, validated by the program team, fixed by the development team, revalidated, closed, and rewarded.

Initial Observation

The testing began from the public login page.

The login page generated a token for unauthenticated visitors. This is common in web applications and is not automatically a vulnerability. However, the important question was whether the backend treated this token only as a request-protection mechanism or incorrectly accepted it as proof of authentication.

That led to the first testing hypothesis:

Can internal API endpoints be reached using only a token from the public login page, without a valid logged-in session?

To test this safely, I obtained the public token without submitting credentials and then sent requests to several API routes that appeared to support device, group, and location functionality.

The result showed that multiple endpoints responded successfully even though there was no authenticated user.

Discovery Path

The vulnerability chain developed in stages.

1. Public Token Was Obtainable Without Login

The public login page returned a request token to unauthenticated users.

This token should not grant access to protected functionality. It should only help protect legitimate requests from cross-site request forgery or similar request-forgery issues.

However, the backend accepted requests containing this token even when no authenticated session was present.

This suggested that the application was validating the presence of a token but not enforcing authentication before processing sensitive API logic.

2. Read Endpoints Returned Sensitive Inventory Data

After obtaining the token, I tested read-only API routes related to IoT inventory.

Several endpoints returned sensitive records without requiring a valid session.

The exposed data included:

• IoT device inventory
• Group information
• Location information
• Tenant-linked metadata
• Internal identifiers used by the platform

The issue was made worse because the backend accepted client-supplied identifiers in the request. Since there was no authenticated server-side user context, the application had no reliable way to verify whether the requester was allowed to access the requested data.

This turned the issue into a cross-tenant broken access control vulnerability.

3. Write Endpoints Accepted Unauthenticated Requests

After confirming unauthenticated read access, I tested whether write functionality was protected correctly.

Certain endpoints accepted parameters intended to modify group or location configuration.

A controlled test request was sent using a harmless, clearly identifiable test value. The server returned a success response.

At this stage, I did not assume the write had actually happened. Some applications return generic success messages even when no real update occurs.

So the next step was to safely verify persistence.

4. Read-Back Confirmed a Real Database Update

To confirm whether the write operation was real, I checked the affected field before and after the request.

Before the request, the field had its original value.

After the unauthenticated write request, the field changed to the controlled test value. The update timestamp also changed.

This confirmed that:

• The unauthenticated request reached the real backend controller.
• The application executed a real database update.
• The success response was not fake.
• The write was not restricted to authenticated users.
• The server did not enforce proper ownership checks.

After confirming the behavior, the value was restored.

This made the impact significantly more serious than a read-only exposure.

Root Cause

The root cause was missing authentication and authorization enforcement on sensitive API routes.

The backend should have rejected unauthenticated requests before they reached business logic. Instead, the routes processed requests as long as the public token and expected parameters were present.

The application also trusted client-supplied identifiers instead of deriving access from the authenticated server-side user identity.

Impact

The impact was critical because the vulnerability allowed both unauthorized data access and unauthorized data modification.

An unauthenticated attacker could access sensitive IoT inventory data and modify configuration records without logging in.

Potential impact included:

• Exposure of connected-device inventory
• Exposure of group and location structure
• Cross-tenant data access
• Unauthorized modification of group names
• Unauthorized modification of location names
• Corruption of customer configuration
• Operational disruption
• Increased risk of targeted follow-up attacks

Final Result

The vulnerability was responsibly reported, validated, fixed, revalidated, closed, and rewarded.

This case is a strong example of how a seemingly normal public token can reveal a much deeper broken access control issue when backend routes are not properly protected.