DEF-021 — POST /register API does not enforce phone-number uniqueness

High severity
New
Defect DEF-021 — Severity: High · Status: New
Published

2026-06-14

DEF-021 — POST /register API does not enforce phone-number uniqueness

Summary

The backend POST /register endpoint accepts a registration request with a phone number that is already associated with an existing account, without returning any “phone number already taken” / uniqueness validation error. Calling /register twice in a row with the same phone number (+1 5196399584) but different emails both returned status: "1" with “OTP sent successfully”, indicating the endpoint performs no phone-number uniqueness check at all.

Environment

  • Platform: DriveLink Backend API
  • API Base: https://dxbitprojects.com/drivelinkapp/public/api/v1
  • Endpoint: POST /register
  • Area: Registration / Input Validation
  • Requirement(s): FR-01 (User Registration)
  • Date Reported: 2026-06-14
  • Testing Phase: Backend API Regression Testing

Steps to Reproduce

  1. Call POST /register with phone 5196399584, dial code +1, and email ahmadshrif+testingaccount@gmail.com
  2. Observe response: status: "1", “OTP sent successfully”
  3. Call POST /register again with the same phone 5196399584, dial code +1, but a different email ahmadshrif+testingaccount2@gmail.com
  4. Observe response: status: "1", “OTP sent successfully” — no error about the phone number already being in use

Expected Behaviour

If a phone number is already associated with an existing (non-deleted) account, POST /register should reject the request with a validation error (e.g. “phone number already taken”), consistent with the error the iOS app surfaces to users.

Actual Behaviour

POST /register accepts the same phone number across multiple registration attempts with different emails, returning a successful “OTP sent successfully” response each time with no uniqueness validation on the phone field.

Impact

  • The phone-number uniqueness check that the iOS app relies on (and surfaces as “phone number already taken”) is not enforced by /register itself — it must live in a different code path (e.g. a pre-check call or the OTP-verification step), making the overall registration flow inconsistent and harder to validate
  • Potential for duplicate/multiple accounts to be created against the same phone number if a client bypasses whatever client-side or secondary check currently blocks this
  • Related to [[DEF-020]] (deleted account’s phone still blocked on iOS) — both findings surfaced during the same investigation but are distinct issues: DEF-020 is about a phone number being blocked when it shouldn’t be, while this defect is about /register not blocking a phone number when it arguably should

Severity

High — Core registration input validation (phone-number uniqueness) is missing at the API level, with downstream effects on data integrity and consistency with client-facing behaviour.

Status

New

Reported By

QA / Testing Team