The city's 311 mobile app exposes a citizen UI, backend APIs, and network entry points. How should security testing be scoped across those surfaces?
Select an answer to reveal the explanation.
Short Explanation
A 311 app is three doors—screen, wires, and API. Each can fail differently, so test all three. Pretty splash art, ‘network will save us,’ or admin-only scope leaves citizen-facing cracks unchecked.
Full Explanation
Interface testing in CISSP assessment practice covers UI, network, and API boundaries because each presents unique attack paths and control failures. A city’s 311 mobile app exposes a citizen-facing UI (client-side trust, deep links, local storage), backend APIs (authn/authz, injection, mass assignment), and network entry points (TLS, exposure, segmentation). Scoping security testing across all three surfaces ensures flaws unique to each layer are not assumed away by controls elsewhere.
Testing only splash-screen graphics ignores the APIs and network paths where most data exposure and abuse occur. Assuming network controls make API testing unnecessary confuses perimeter defense with application authorization—APIs remain attackable through allowed channels. Limiting testing to internal admin tools while excluding the public UI leaves the citizen attack surface—the one most exposed—unexamined.
Exam caveat: Domain 6 interface testing explicitly includes application, network, and user interfaces. When a stem lists multiple surfaces, the correct approach is inclusive testing of each, not single-surface shortcuts.
Operational check: Build a 311 test scope that lists UI flows, API endpoints (including undocumented ones), and network ingress points; assign techniques per surface; require evidence packages for each before release; and track residual API authz issues separately from UI cosmetic defects.