crAPI Security assessment report

Vulnerability: [FAIL] Broken Function Level Authorization - Workshop - Management Users Endpoint

Description:
The management endpoint /workshop/api/management/users/all -- which should be restricted to administrators -- is reachable by an ordinary authenticated user (role=user). The endpoint returns data for every user in the application.

Impact:
Confidentiality: any ordinary user can download PII for all users (17 accounts): email addresses, phone numbers, and credit balances. Function-level authorization is not enforced.

CWE:
CWE-285: Improper Authorization (related to CWE-639)

OWASP:
API5:2023 - Broken Function Level Authorization (and API3:2023 - Excessive Data Exposure)

Scenario:
Normal: an ordinary user only sees their own account data. Exploitation: the same ordinary user calls the management endpoint /workshop/api/management/users/all -> 200 returns PII for every user. The end result demonstrates CIA (Confidentiality).

Endpoint:
GET http://127.0.0.1:8888/workshop/api/management/users/all

Affected Feature:
User Management Endpoint (crapi-workshop)

Remediation:
- Enforce role-based authorization on every management/administrative endpoint; verify role=admin server-side.
- Do not rely on the absence of a UI link as an access control.
- Minimize the data returned.

POC:
1) (Screenshot 1) NORMAL: GET /identity/api/v2/user/dashboard with an ordinary user token -> 200, own account data only (id=8).
2) (Screenshot 2) EXPLOITATION + CIA: GET /workshop/api/management/users/all with the SAME ordinary user token -> 200 returns PII for every user (17 accounts).

Vulnerability: [FAIL] Broken Object Level Authorization - Vehicle - Location Tracking

Description:
The vehicle location endpoint returns another user's GPS position given only a vehicle UUID. The server verifies authentication but does not verify object ownership (BOLA/IDOR).

Impact:
Confidentiality: real-time physical location tracking of other users plus disclosure of their name and email; potential stalking/targeting.

CWE:
CWE-639: Authorization Bypass Through User-Controlled Key

OWASP:
API1:2023 - Broken Object Level Authorization

Scenario:
Normal: the attacker reads the location of their own vehicle -> 200. Exploitation: the UUID is swapped for the victim's vehicle -> 200 returns the victim's location and email -> CIA (Confidentiality).

Endpoint:
GET http://127.0.0.1:8888/identity/api/v2/vehicle/{vehicleId}/location

Affected Feature:
Vehicle Location Tracking (crapi-identity)

Remediation:
- Verify vehicle ownership against the user in the token before returning the location.
- Apply centralized object-level authorization checks.

POC:
1) (Screenshot 1) NORMAL: GET /identity/api/v2/vehicle/9b3ce26b-d797-404b-a961-09d7e45e0d1b/location (own vehicle) with the attacker token -> 200.
2) (Screenshot 2) EXPLOITATION + CIA: replace the UUID in the path with 8ba9066d-8484-4ef7-8a7b-c0fa3cb2e687 (the VICTIM's vehicle), same token -> 200 returns GPS coordinates and the victim's email ([REDACTED-EMAIL]).

Vulnerability: [FAIL] Broken Object Level Authorization - Workshop - Mechanic Report

Description:
The mechanic_report endpoint accepts a sequential report_id and returns service reports belonging to other users (VIN and owner email) without verifying any relationship to the caller.

Impact:
Confidentiality: cross-user disclosure of VIN, vehicle details, and owner email for every service report.

CWE:
CWE-639: Authorization Bypass Through User-Controlled Key

OWASP:
API1:2023 - Broken Object Level Authorization (and API3:2023 - BOPLA)

Scenario:
Normal: read report_id=1. Exploitation: enumerate report_id (e.g. =2) -> discloses a different VIN and owner email -> CIA (Confidentiality).

Endpoint:
GET http://127.0.0.1:8888/workshop/api/mechanic/mechanic_report?report_id={id}

Affected Feature:
Mechanic Service Report (crapi-workshop)

Remediation:
- Verify that report_id belongs to the calling user/mechanic.
- Use UUIDs and minimize the fields returned.

POC:
1) (Screenshot 1) NORMAL: GET mechanic_report?report_id=1 with the attacker token -> 200 (reference).
2) (Screenshot 2) EXPLOITATION + CIA: change the parameter to report_id=2 -> 200 discloses another owner's VIN and email ([REDACTED-EMAIL]).

Vulnerability: [FAIL] Improper Inventory Management - Authentication - OTP Endpoint Versions

Description:
The OTP verification endpoint exists in several versions that are active at the same time: the older /identity/api/auth/v2/check-otp still works alongside the current v3. Retired/undocumented versions enlarge the attack surface and may enforce different security controls.

Impact:
Confidentiality & Integrity: the still-live legacy version widens the attack surface; an attacker can pick the version with the weakest protection (e.g. for OTP brute force).

CWE:
CWE-1059: Insufficient Technical Documentation (related to CWE-1104: Use of Unmaintained Third Party Components / legacy versions)

OWASP:
API9:2023 - Improper Inventory Management

Scenario:
v3 (the current version) is active. Exploitation: v2 (the legacy version) is also still active -> improper inventory (the legacy version was never decommissioned).

Endpoint:
POST http://127.0.0.1:8888/identity/api/auth/v2/check-otp
POST http://127.0.0.1:8888/identity/api/auth/v3/check-otp

Affected Feature:
Password Reset via OTP (crapi-identity)

Remediation:
- Disable/retire legacy API versions (v2) that are no longer used.
- Maintain an API version inventory and document the active endpoints.
- Apply uniform security controls across every version still in service.

POC:
1) (Screenshot 1) POST /identity/api/auth/v3/check-otp (current version) -> responds.
2) (Screenshot 2) POST /identity/api/auth/v2/check-otp (LEGACY version) -> still responds (Invalid OTP), proving the legacy version has not been decommissioned.

Vulnerability: [FAIL] JWT Signature Not Verified - Authentication - JWT Validation

Description:
The crAPI identity service does not verify JWT signatures. A token with the header alg:none and no signature is accepted, and an RS256 token whose payload was modified without re-signing is also accepted. An attacker can forge a token for any user and escalate the role to admin.

Impact:
Confidentiality: victim account data can be read. Integrity: identity and role (admin) can be forged -> full account takeover of every user without credentials.

CWE:
CWE-347: Improper Verification of Cryptographic Signature

OWASP:
API2:2023 - Broken Authentication

Scenario:
Normal: a legitimate role=user token only accesses its own data. Exploitation: a forged token (alg:none / edited RS256) impersonates an ADMIN (sub=[REDACTED-EMAIL], role=admin) -> accesses the admin account (id=5) -> CIA (Confidentiality + Integrity).

Endpoint:
GET http://127.0.0.1:8888/identity/api/v2/user/dashboard (all JWT-based identity endpoints)

Affected Feature:
JWT-based authentication (crapi-identity)

Remediation:
- Verify the JWT signature with the RS256 public key on every request.
- Explicitly reject alg:none and apply algorithm allow-listing (RS256 only).
- Use a mature JWT library; validate exp/iss/aud.

POC:
1) (Screenshot 1) NORMAL: GET /identity/api/v2/vehicle/vehicles with a legitimate RS256 token (shown in full) -> 200, own data only.
2) (Screenshot 2) alg:none PROCESS: break down the original token, base64url-decode the header and payload, change alg to 'none' with no signature and set the payload to sub=[REDACTED-EMAIL]/role=admin, then reassemble the forged token (shown in full).
3) (Screenshot 3) EXPLOITATION: send the alg:none token -> 200 returns the ADMIN account (id=5, ROLE_ADMIN).
4) (Screenshot 4) RS256 tampering PROCESS: take the original RS256 token, edit the payload to sub=[REDACTED-EMAIL] and role=admin, then reattach the OLD signature without re-signing (token shown in full).
5) (Screenshot 5) CIA IMPACT: send the tampered RS256 token -> still 200 and returns the ADMIN account -> proving the signature is not verified (Confidentiality + Integrity).

Vulnerability: [FAIL] NoSQL Injection - Community - Coupon Validation

Description:
The validate-coupon endpoint passes the JSON value coupon_code straight into a MongoDB query without type sanitization. Query operators (e.g. $ne, $gt) match any coupon without knowing its code.

Impact:
Confidentiality: valid coupon codes and values are disclosed. Integrity: coupon validation is bypassed, enabling discount abuse.

CWE:
CWE-943: Improper Neutralization of Special Elements in Data Query Logic (NoSQL Injection)

OWASP:
API8:2023 - Security Misconfiguration (Injection)

Scenario:
Normal: a valid string coupon code (TRAC075) -> 200. Exploitation: coupon_code is replaced with a NoSQL operator ($ne/$gt) -> discloses coupons without knowing the code -> CIA (Confidentiality + Integrity).

Endpoint:
POST http://127.0.0.1:8888/community/api/v2/coupon/validate-coupon

Affected Feature:
Coupon Validation (crapi-community)

Remediation:
- Enforce the string type on coupon_code; reject objects/operators.
- Use parameterized queries/sanitization and validate the input schema.

POC:
1) (Screenshot 1) NORMAL: POST validate-coupon with the valid string coupon_code "TRAC075" -> 200.
2) (Screenshot 2) EXPLOITATION: change coupon_code to the operator {"$ne":"x"} -> 200 discloses a valid coupon without knowing its code.
3) (Screenshot 3) CIA IMPACT: the operator {"$gt":""} also discloses a coupon -> confirms NoSQL injection.

Vulnerability: [FAIL] OTP Bruteforce Protection Bypass - Authentication - Password Reset

Description:
Reset OTP verification (/v3/check-otp) locks after 9 attempts per session, BUT this limit is reset every time /forget-password is called, and that endpoint itself has no rate limit or CAPTCHA. The brute-force protection can therefore be bypassed with a repeating cycle.

Impact:
Confidentiality & Integrity: account takeover (ATO) of any user whose email is known, by brute-forcing the 4-digit OTP (10,000 combinations) with no effective obstacle.

CWE:
CWE-307: Improper Restriction of Excessive Authentication Attempts

OWASP:
API2:2023 - Broken Authentication

Scenario:
Normal: request an OTP and make one attempt (Invalid). Exploitation: repeating forget-password without limit resets the lockout -> brute-force the 4-digit OTP -> ATO -> CIA (Confidentiality + Integrity).

Endpoint:
POST http://127.0.0.1:8888/identity/api/auth/v3/check-otp
POST http://127.0.0.1:8888/identity/api/auth/forget-password

Affected Feature:
Password Reset via OTP (crapi-identity)

Remediation:
- Apply PERSISTENT per-account rate limiting + lockout (not reset by a new OTP request).
- Throttle and add CAPTCHA to forget-password.
- Use OTPs of >=6 digits with a short expiry.

POC:
1) (Screenshot 1) NORMAL: POST forget-password {victim email} -> 200, OTP sent.
2) (Screenshot 2) NORMAL: POST v3/check-otp with one wrong attempt -> Invalid OTP.
3) (Screenshot 3) EXPLOITATION + CIA: after the lockout, call forget-password again (200, no throttling) -> the counter is reset and a new OTP is issued; repeat the cycle [reset -> 9 guesses] until the OTP is guessed -> victim password reset (ATO).

Vulnerability: [FAIL] Server-Side Request Forgery - Workshop - Contact Mechanic

Description:
The contact_mechanic endpoint accepts a full URL in the mechanic_api parameter and performs a server-side HTTP request to that URL, then reflects the response. An attacker can point it at INTERNAL services that are not exposed publicly. Escalation: the SSRF is aimed at the internal MailHog mail server (mailhog:8025) to read every user's email, harvest the victim's password-reset OTP, and then reset the victim's password -> Account Takeover.

Impact:
Confidentiality + Integrity (Critical): the SSRF reads the entire internal mailbox (mailhog, 45 emails), including other users' reset OTPs/tokens, which are then used to take over victim accounts without knowing their credentials. Applies to any account whose email is known.

CWE:
CWE-918: Server-Side Request Forgery (SSRF)

OWASP:
API7:2023 - Server Side Request Forgery

Scenario:
Normal: mechanic_api points to a legitimate mechanic endpoint. Exploitation (chain): SSRF -> internal MailHog -> read victim email -> harvest OTP -> reset victim password -> log in as the victim (ATO). The end result demonstrates CIA (Confidentiality + Integrity).

Endpoint:
POST http://127.0.0.1:8888/workshop/api/merchant/contact_mechanic

Affected Feature:
Contact Mechanic / mechanic API integration (crapi-workshop)

Remediation:
- Do not accept full URLs from the client; use an allow-list of legitimate mechanic hosts/endpoints.
- Block internal schemes and IP/host ranges (loopback, RFC1918, internal service names such as mailhog/crapi-identity).
- Do not reflect raw upstream responses to the client.
- Network segmentation: internal services (MailHog, actuator) must not be reachable from any service that accepts URL input.

POC:
1) (Screenshot 1) NORMAL: contact_mechanic with mechanic_api set to a legitimate mechanic endpoint -> the server fetches it server-side.
2) (Screenshot 2) EXPLOITATION: mechanic_api = http://mailhog:8025/api/v2/messages -> the SSRF reads the ENTIRE internal mailbox (45 emails from all users).
3) (Screenshot 3) HARVEST: mechanic_api = http://mailhog:8025/api/v2/search?kind=to&query=[REDACTED-EMAIL] -> reads the victim's OTP email; the 4-digit OTP is harvested.
4) (Screenshot 4) CHAIN: the harvested OTP is sent to /identity/api/auth/v3/check-otp -> 'OTP verified', the victim's password is reset.
5) (Screenshot 5) CIA IMPACT: log in as the victim with the new password -> token issued -> Account Takeover.

Vulnerability: [FAIL] Unauthenticated Order Access - Shop - Order Details

Description:
The endpoint GET /workshop/api/shop/orders/{order_id} returns full order details without authentication, and order_id is sequential and easy to enumerate.

Impact:
Confidentiality: PII for every customer (email, phone number, product, status, transaction) is disclosed to unauthenticated parties, including administrator accounts.

CWE:
CWE-306: Missing Authentication for Critical Function

OWASP:
API5:2023 - Broken Function Level Authorization (and API1:2023 - BOLA)

Scenario:
Normal: access an order with a token -> 200. Exploitation: remove the Authorization header -> still 200 plus PII -> CIA (Confidentiality).

Endpoint:
GET http://127.0.0.1:8888/workshop/api/shop/orders/{order_id}

Affected Feature:
Shop Order History/Details (crapi-workshop)

Remediation:
- Require authentication plus ownership verification (order.user == caller).
- Use non-sequential identifiers (UUIDs).
- Apply centralized authorization.

POC:
1) (Screenshot 1) NORMAL: GET /workshop/api/shop/orders/5 with a valid Authorization header -> 200.
2) (Screenshot 2) EXPLOITATION + CIA: resend the same request WITHOUT the Authorization header -> still 200 and discloses the order owner's PII ([REDACTED-EMAIL]).

Vulnerability: [FAIL] Unrestricted Resource Consumption - Authentication - Login Rate Limiting

Description:
The crAPI login endpoint applies neither rate limiting nor account lockout. Repeated failed login attempts are not limited, enabling brute force/credential stuffing and unbounded consumption of server resources.

Impact:
Availability: the server can be flooded with authentication requests without restriction. Confidentiality: enables credential brute force to take over accounts.

CWE:
CWE-307: Improper Restriction of Excessive Authentication Attempts (CWE-770: Allocation of Resources Without Limits)

OWASP:
API4:2023 - Unrestricted Resource Consumption

Scenario:
Normal: a single failed login -> 401. Exploitation: 20 consecutive attempts -> all 401 with no 429/lockout, proving there is no restriction.

Endpoint:
POST http://127.0.0.1:8888/identity/api/auth/login

Affected Feature:
Login Authentication (crapi-identity)

Remediation:
- Apply per-account/IP rate limiting and progressive account lockout.
- Add CAPTCHA/anti-automation and anomaly detection.
- Limit concurrency/requests per client.

POC:
1) (Screenshot 1) NORMAL: POST /identity/api/auth/login with a wrong password -> 401.
2) (Screenshot 2) EXPLOITATION: send 20 consecutive login attempts -> all 401 with no HTTP 429/lockout, proving there is no rate limiting.

Vulnerability: [FAIL] Unsafe Consumption of APIs - Workshop - Contact Mechanic Upstream

Description:
The contact_mechanic endpoint consumes the response from the mechanic API (a client-controlled URL) and reflects it back to the user without validating or filtering its structure or content. The application implicitly trusts data from the upstream API.

Impact:
Confidentiality & Integrity: untrusted upstream data (which the attacker can control) is reflected/processed as-is; this can be used to exfiltrate internal responses or inject content the application trusts.

CWE:
CWE-20: Improper Input Validation (related to CWE-345: Insufficient Verification of Data Authenticity)

OWASP:
API10:2023 - Unsafe Consumption of APIs

Scenario:
Normal: the workshop consumes a legitimate mechanic API. Exploitation: the upstream URL is swapped for an arbitrary one -> the raw response is reflected without validation.

Endpoint:
POST http://127.0.0.1:8888/workshop/api/merchant/contact_mechanic

Affected Feature:
Contact Mechanic / mechanic API integration (crapi-workshop)

Remediation:
- Validate and filter upstream responses (schema, content type) before processing/reflecting them.
- Restrict upstream destinations to a trusted allow-list (see also the SSRF finding).
- Do not reflect raw responses to the client.

POC:
1) (Screenshot 1) NORMAL: contact_mechanic consumes the mechanic API and includes its response.
2) (Screenshot 2) EXPLOITATION: change mechanic_api to an arbitrary URL -> the workshop reflects the raw upstream response without validation (unsafe consumption).

Vulnerability: [PASS] Broken Object Level Authorization - Shop - Return Order

Description:
Tested whether the order return action (return_order) is vulnerable to BOLA by attempting to return an order belonging to another user.

Impact:
No impact: the server enforces ownership authorization and rejects the request (403).

CWE:
CWE-639: Authorization Bypass Through User-Controlled Key (tested, not vulnerable)

OWASP:
API1:2023 - Broken Object Level Authorization (negative test)

Scenario:
Exploitation: return_order?order_id=1 (not owned by the attacker) -> 403. PASS (control holds, CIA not violated).

Endpoint:
POST http://127.0.0.1:8888/workshop/api/shop/orders/return_order?order_id={id}

Affected Feature:
Order Return (crapi-workshop)

Remediation:
Keep the ownership check on the return action (the current state is correct).

POC:
1) (Screenshot 1) EXPLOITATION: POST return_order?order_id=1 (an order owned by another user) with the attacker token -> 403 "You are not allowed to access this resource!" (control holds).

Vulnerability: [PASS] Broken Object Level Authorization - Vehicle - Location Tracking (Unauthenticated)

Description:
Tested access to the vehicle location endpoint without any authentication.

Impact:
No impact: the server requires authentication and rejects the request (401).

CWE:
CWE-306: Missing Authentication for Critical Function (tested, not vulnerable on this path)

OWASP:
API1:2023 - Broken Object Level Authorization (negative test - unauthenticated path)

Scenario:
Normal: access your own location with a token -> 200. Exploitation: remove the token -> 401. PASS (authentication control holds).

Endpoint:
GET http://127.0.0.1:8888/identity/api/v2/vehicle/{vehicleId}/location

Affected Feature:
Vehicle Location Tracking (crapi-identity)

Remediation:
Keep the authentication requirement; additionally add object ownership verification (see the related [FAIL] finding).

POC:
1) (Screenshot 1) NORMAL: GET /identity/api/v2/vehicle/9b3ce26b-d797-404b-a961-09d7e45e0d1b/location for your own vehicle with a token -> 200.
2) (Screenshot 2) EXPLOITATION: resend WITHOUT the Authorization header -> 401 (authentication control holds).

Vulnerability: [PASS] Broken Object Level Authorization - Workshop - Mechanic Report (Unauthenticated)

Description:
Tested access to the mechanic_report endpoint without authentication.

Impact:
No impact: the server requires authentication and rejects the request (401).

CWE:
CWE-306: Missing Authentication for Critical Function (tested, not vulnerable on this path)

OWASP:
API1:2023 - Broken Object Level Authorization (negative test - unauthenticated path)

Scenario:
Normal: read a report with a token -> 200. Exploitation: remove the token -> 401. PASS (authentication control holds).

Endpoint:
GET http://127.0.0.1:8888/workshop/api/mechanic/mechanic_report?report_id={id}

Affected Feature:
Mechanic Service Report (crapi-workshop)

Remediation:
Keep the authentication requirement; add object ownership verification (see the related [FAIL] finding).

POC:
1) (Screenshot 1) NORMAL: GET mechanic_report?report_id=1 with a token -> 200.
2) (Screenshot 2) EXPLOITATION: resend WITHOUT the Authorization header -> 401 (authentication control holds).

Vulnerability: [PASS] Mass Assignment - Authentication - User Registration

Description:
Tested whether the registration endpoint is vulnerable to mass assignment by injecting privileged fields (role=admin, isAdmin=true) into the signup body.

Impact:
No impact: the server ignores privileged fields, so no privilege escalation occurs.

CWE:
CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes (tested, not vulnerable)

OWASP:
API3:2023 - Broken Object Property Level Authorization (negative test)

Scenario:
Normal: standard registration. Exploitation: signup + role=admin/isAdmin. Result: login shows the role remains user -> PASS (control holds, CIA not violated).

Endpoint:
POST http://127.0.0.1:8888/identity/api/auth/signup

Affected Feature:
User Registration (crapi-identity)

Remediation:
Keep the allow-list of fields the client may set during registration (the current state is correct).

POC:
1) (Screenshot 1) NORMAL: signup with standard fields -> 200.
2) (Screenshot 2) EXPLOITATION: signup with the addition of role=admin & isAdmin=true -> 200 (registered).
3) (Screenshot 3) RESULT: log in to that account -> the JWT role remains "user" -> privileged fields were ignored (control holds).

Vulnerability: [PASS] NoSQL Injection - Community - Coupon Validation (Normal Input)

Description:
Tested coupon validation with ordinary string input (valid and unknown), without NoSQL operators.

Impact:
No impact: valid codes are accepted and unknown codes are rejected as expected.

CWE:
CWE-943: NoSQL Injection (negative test for ordinary string input)

OWASP:
API8:2023 - Security Misconfiguration (negative test - normal input)

Scenario:
Normal: valid code TRAC075 -> 200. Test: unknown random string -> rejected. PASS (normal input validation holds). Operator injection is covered in [FAIL].

Endpoint:
POST http://127.0.0.1:8888/community/api/v2/coupon/validate-coupon

Affected Feature:
Coupon Validation (crapi-community)

Remediation:
Enforce the string type and reject operators/objects (see the related [FAIL] finding).

POC:
1) (Screenshot 1) NORMAL: coupon_code="TRAC075" (valid) -> 200.
2) (Screenshot 2) TEST: coupon_code="INVALID_RANDOM_XYZ" (unknown string) -> rejected (normal validation holds).

Vulnerability: [PASS] OTP Bruteforce Protection - Authentication - Password Reset (Per-Session Lockout)

Description:
Tested OTP brute force within a single OTP session without requesting a new OTP.

Impact:
No impact on this path: lockout triggers after 9 attempts (HTTP 503), so per-session brute force fails.

CWE:
CWE-307: Improper Restriction of Excessive Authentication Attempts (per-session control PRESENT)

OWASP:
API2:2023 - Broken Authentication (negative test - per-session path)

Scenario:
Normal: one OTP attempt -> Invalid. Exploitation: brute force -> lockout 503 after 9 attempts. PASS (per-session control holds). The bypass is covered in [FAIL].

Endpoint:
POST http://127.0.0.1:8888/identity/api/auth/v3/check-otp

Affected Feature:
Password Reset via OTP (crapi-identity)

Remediation:
Make the lockout PERSISTENT per account so it cannot be reset by a new OTP request (see the related [FAIL] finding).

POC:
1) (Screenshot 1) NORMAL: POST v3/check-otp with one wrong attempt -> Invalid OTP.
2) (Screenshot 2) EXPLOITATION: repeat attempts; on the 10th attempt the lockout triggers -> 503 "You've exceeded the number of attempts" (per-session control holds).

Vulnerability: [PASS] Unrestricted Access to Sensitive Business Flow - Shop - Coupon Claim

Description:
Tested whether a sensitive business flow (claiming a coupon to top up the balance) can be abused by claiming the same coupon repeatedly (replay).

Impact:
No impact: the server rejects a second claim of the same coupon (already claimed); the business flow is limited per user.

CWE:
CWE-837: Improper Enforcement of a Single, Unique Action (tested, not vulnerable)

OWASP:
API6:2023 - Unrestricted Access to Sensitive Business Flows (negative test)

Scenario:
Normal: the first coupon claim succeeds (balance +75). Exploitation: replay the same coupon -> rejected (already claimed). PASS (control holds).

Endpoint:
POST http://127.0.0.1:8888/workshop/api/shop/apply_coupon

Affected Feature:
Coupon Claim / Balance (crapi-workshop)

Remediation:
Keep the per-user coupon claim restriction (the current state is correct).

POC:
1) (Screenshot 1) NORMAL: apply_coupon TRAC075 for the first time -> succeeds, balance increases.
2) (Screenshot 2) EXPLOITATION: apply_coupon TRAC075 again -> rejected 'already claimed' (control holds).