Back to API Practice

Security/Auth trainer

Device Risk Review API Practice

Practice reviewing suspicious devices, risk signals, trusted devices, impossible travel, privacy boundaries, step-up actions, and audit trails.

Start writing test ideasTry API sandbox

How to use this trainer

Choose, send, inspect, write, improve

Safe client-side simulator. No real backend is called and no real data is sent.

  1. 1Choose a preset case
  2. 2Send a simulated request
  3. 3Read the response and QA note
  4. 4Write what you would test
  5. 5Check your coverage

Interactive sandbox

Try the API request

Pick a preset, send a simulated GET /api/auth/devices/risk-review request, inspect the fake response, and turn it into test ideas.

No real device, location, IP, or account data is sent. This is a client-side simulator.

Request

Build the request

GET/api/auth/devices/risk-review

Request JSON

application/json
{
  "deviceId": "dev_laptop_123",
  "includeHistory": true,
  "riskWindowDays": 30
}

Test case presets

Choose a case, inspect the fake response, then write what you would test.

Happy path

Risk signals

Permissions

Validation

Data

Reliability

Response

Fake API result

Send a simulated request to see status, response JSON, QA note, and what to notice. No real backend is called.

List trusted device, suspicious device, unknown device ID, another user risk denied, risk signals, privacy, stale metadata, step-up or revoke actions, risk engine outage, logs, metrics, and accessibility.

Tip: a stronger answer usually mixes happy path, negative cases, state changes, data, backend, UX, accessibility, and risk.

How to structure your answer

Happy pathNegative casesData rulesSecurity/API risksUX/performance
API ReferenceEndpoint, request fields, responses, and business rulesExpand

API reference

Device Risk Review endpoint

Return device-session risk signals and recommended actions without exposing sensitive device or location data.

Endpoint

GET/api/auth/devices/risk-review

Purpose

Return device-session risk signals and recommended actions without exposing sensitive device or location data.

Request fields

  • deviceId: optional device/session identifier
  • includeHistory: include recent signals
  • riskWindowDays: risk history window
  • filters: optional risk level or signal filters

Success response

200 OK

Request body

{
  "deviceId": "dev_laptop_123",
  "includeHistory": true,
  "riskWindowDays": 30
}

Example response body

{
  "deviceId": "dev_laptop_123",
  "riskLevel": "low",
  "signals": ["known_device", "expected_location"],
  "recommendedAction": "none"
}

Errors

  • 400 validation error
  • 401 unauthenticated
  • 403 forbidden or cross-user
  • 404 safe not found
  • 429 rate limited
  • 503 risk engine unavailable

Security notes

  • Do not leak IP/location/device fingerprint details unnecessarily
  • Cross-user and cross-tenant review is denied
  • Risk actions are audited
  • Risk engine failures do not produce false trust

Business rules

  • Risk signals come from trusted auth/session systems
  • High-risk devices can require MFA or revocation
  • Stale or missing metadata is represented clearly
  • Privacy-sensitive location data is minimized
  • Risk state updates after login, logout, trust, or revoke