I85PREP
⌘ K
NISP Level 2 study materials
NISP Level 2 study resources

NISP Level 2: Application and Data Security

NISP Level 2 · Work through your exam, one topic at a time.

All guide sections

Application and Data Security

Application and Data Security examines how software is built, how it fails, and how data is protected through its lifecycle. Questions typically present a code snippet, an API behaviour or a data-handling scenario and ask for the correct control.

The recurring flaw classes

  • Broken access control - the server trusts a client-supplied identifier, so changing order_id=1001 to 1002 reveals another user's record. The fix is a server-side authorisation check on every object.
  • Injection - SQL, command, LDAP and template injection all arise from mixing data with code. Use parameterised queries and allow-list input validation.
  • XSS - reflected, stored and DOM-based; mitigate with contextual output encoding, a Content-Security-Policy, and HttpOnly cookies.
  • CSRF - the browser attaches credentials automatically; use anti-CSRF tokens and SameSite cookies.
  • SSRF and unsafe deserialisation - restrict outbound destinations and never deserialise untrusted input.
  • Session and identity failures - rotate session IDs at login, set Secure/HttpOnly, enforce timeouts and server-side logout.

Data lifecycle controls

Classify data first, then apply controls: encryption at rest and in transit, database activity monitoring, DLP for egress, masking in non-production environments. Distinguish de-identification (去标识化) - reversible with additional information - from anonymisation (匿名化), which is irreversible and falls outside personal-information rules. Backups follow 3-2-1: three copies, two media types, one off-site, with restore tests.

Worked example

A report endpoint returns any invoice by ID to a logged-in user. The developer adds client-side JavaScript that hides other users' buttons. Reasoning: the vulnerability is server-side object-level authorisation; hiding UI elements changes nothing because the attacker edits the request directly. The fix is to verify that the session principal owns the requested invoice, and to log the denied attempt. Testing requires two accounts and a proxy, not a browser view.

Traps

  • Relying on client-side validation or hidden form fields as a security control.
  • Confusing XSS (script execution in a victim's browser) with CSRF (forged request using the victim's session).
  • Believing encryption substitutes for access control; an authorised reader can still misuse data.
  • Calling pseudonymised data "anonymous" and dropping protection obligations.
  • Testing only the happy path and ignoring error messages that leak stack traces.