Note to Security Team
Hi Team,
I believe this may fall under a secure design / business logic issue rather than a direct vulnerability. If it meets your bug bounty criteria, please consider it accordingly; otherwise, I’m sharing this as a best practice improvement.
Summary
The application allows a user to set a contact as both “favorite” and “hidden” simultaneously by modifying the request, even though the UI restricts this behavior. This leads to an inconsistent and logically conflicting state.
Affected Endpoint
https:
Category
Secure Design Issue
Business Logic Flaw
Description
The UI enforces a restriction where a contact cannot be marked as favorite and hidden at the same time. However, this restriction is only implemented client-side.
By intercepting and modifying the request, both attributes can be set simultaneously, resulting in a state that contradicts the intended design.
Steps to Reproduce
Navigate to:
https:
Select any user/contact.
Mark the user as favorite.
Capture the request:
PATCH /account/people/{id}
Original request body:
{"favorite": true, "hidden": false}
Modify request to:
{"favorite": true, "hidden": true}
Send the request.
Observe:
The user is now both favorite and hidden.
Expected Behavior
Server should enforce mutual exclusivity:
A user cannot be both favorite and hidden.
Invalid state combinations should be rejected.
Actual Behavior
Server accepts conflicting states.
No backend validation for business logic constraints.
Severity
(Secure Design / Best Practice)
Recommendation
Enforce server-side validation for mutually exclusive states.
Add validation rules such as:
If hidden = true → favorite must be false
Do not rely solely on client-side restrictions.
Consider adding integrity checks before saving state.