Application and Data Security: Controls, Worked Examples and Exam Traps

Follow one refund request through transport, identity, policy, validation, database, and audit controls. Then work through toy RSA arithmetic and key exam traps.

KnowledgeGate Team

Exam prep & CS education

Updated 20 Sep 20265 min read

Security terms are easy to memorise separately, but exam questions usually describe one request or data item and ask which control actually prevents the failure. Securing a refund request requires authentication, authorisation, validation, storage, and audit. Toy public-key arithmetic shows why the chosen cryptographic primitive matters. Application security protects software behaviour and interfaces, while data security protects information throughout its lifecycle. A control at the wrong boundary fails.

Application security and data security protect different parts of one system

Application security protects code, APIs, sessions, business rules, dependencies, and deployment settings. Data security protects data at rest, in transit, and in use through classification, access, integrity, retention, backup, and disposal. They overlap whenever software reads or changes information.

Confidentiality, integrity, and availability are goals; controls are mechanisms. Encryption mainly supports confidentiality. A MAC supports integrity and source authentication for parties sharing a key. Backups aid recovery and availability. Access control limits actions.

Keep this chain clear:

  • Asset: customer order 420.

  • Threat: an unauthorised refund.

  • Vulnerability: a missing role check.

  • Exploit attempt: a forged refund request.

  • Preventive control: server-side authorisation.

  • Residual risk: a permitted finance account may still be stolen.

Place these ideas beside networks, databases, and operating systems through CS Fundamentals for Exams & Placements.

A secure request passes several independent gates

A request should pass encrypted transport, parsing and size limits, authentication, token checks, object-level and action-level authorisation, validation, safe database access, output encoding, logging, and monitoring. This is defence in depth: passing one gate never makes another optional.

Authentication asks, "Is this caller u17?" Authorisation asks, "May support user u17 refund order 420?" Audit records the attempt and server decision.

Least privilege grants only needed permissions; deny by default rejects anything not allowed. support may read order status but cannot refund, while finance may refund an eligible order within policy. Hiding the button is not authorisation because a caller can send the request directly.

Worked request: validate, authorise, update, and audit one refund

The row is orders(id=420, owner=u23, status=PAID, amount=6400). Request A is POST /api/orders/420/refund, body {"refundAmount":6400}, with claims sub=u17, role=support. Policy permits finance to refund a PAID order when refundAmount <= amount and refundAmount <= 10000; support may only read it.

Evaluate Request A in order. The token identifies u17; 420 is a positive integer; 6400 is positive, 6400 <= 6400, and 6400 <= 10000. The role check fails because support lacks refund. The server returns 403, keeps PAID, and records DENIED_ROLE. Valid input is not necessarily authorised input.

Request B carries sub=u09, role=finance and the same body. Checks pass, so the server executes UPDATE orders SET status=?, refund_amount=? WHERE id=? AND status=? with ("REFUNDED", 6400, 420, "PAID"). It requires affected rows 1, then audits actor u09, order 420, before PAID, after REFUNDED, result SUCCESS. Count 0 means conflict.

For hostile id="420 OR 1=1", strict integer parsing returns 400. The parameterised query is the second layer that prevents input from becoming SQL syntax.

Refund request flow where a support call is denied 403, a finance call updates the order to REFUNDED, and an injected id gives 400.

Choose the primitive by the missing security property

Primitive

What it supplies

Important boundary

Encryption

Reversible confidentiality with a key

Alone, it need not prove integrity

Cryptographic hash

One-way, fixed-length digest

A bare hash does not authenticate attacker-controlled data

MAC

Integrity and origin authentication within a key-sharing group

All verifying parties share the secret

Digital signature

Integrity and origin authentication with private signing and public verification keys

The private key needs protection

Salted adaptive password hash

Deliberately costly password verification

It is not reversible password storage

Use educational RSA values that are insecure for real systems. Choose p=11, q=13, so n=11*13=143 and phi(n)=10*12=120. Let e=7; its inverse is d=103 because 7*103=721=6*120+1.

For m=9, 9^2 mod 143=81 and 9^4 mod 143=126. Therefore 9^7 mod 143=(126*81*9) mod 143. First, 126*81 mod 143=53; then 53*9 mod 143=48. The ciphertext is c=48.

For decryption, 103=64+32+4+2+1. Repeated squaring gives residues for powers 1, 2, 4, 8, 16, 32, 64 as 48, 16, 113, 42, 48, 16, 113. Multiply the selected residues modulo 143: 113*16 mod 143=92, 92*113 mod 143=100, 100*16 mod 143=27, and 27*48 mod 143=9. Thus 48^103 mod 143=9.

This shows inverse exponents, not production security. Real applications need vetted libraries, safe sizes, padding, key management, and usually hybrid authenticated encryption.

Toy RSA example with p=11, q=13, n=143, e=7, d=103, encrypting m=9 to c=48 and decrypting the ciphertext back to 9.

Match application attacks to the control that breaks the path

Attack

Cause

Control that breaks the path

SQL injection

Data is interpreted as query syntax

Strict validation and parameterised queries

Cross-site scripting

Untrusted content becomes browser code

Context-appropriate output encoding, plus a restrictive browser policy

Cross-site request forgery

A browser sends ambient credentials

Anti-CSRF tokens and appropriate cookie controls

Broken access control

A server-side policy check is missing

Authorisation on every object and action

Secure transport cannot repair a stolen session, over-permissive account, plaintext log, or public backup. Revoke stolen sessions, minimise logged secrets, restrict backups, and encrypt sensitive stored data with managed keys.

Application Layer Protocols: DNS Walk-Through, HTTP locates requests and responses. HTTPS protects transport; validation, authorisation, and safe rendering remain application duties.

Exam traps confuse goals, mechanisms, and boundaries

Ask which property or decision is missing:

  1. Authentication asks "who are you?" Authorisation asks "may you act on this object?"

  2. Encryption does not automatically guarantee integrity. Look for authenticated encryption or a protected integrity check.

  3. Password hashing needs a unique salt and a deliberately expensive password-hashing function.

  4. A firewall cannot repair a broken refund rule, and input validation cannot replace a role check.

  5. A backup aids recovery but remains a sensitive copy needing access control and encryption.

Eight lowercase characters give 26^8=208,827,064,576 candidates. At 10^9 guesses per second, division gives about 208.8 seconds. At 1000 per second, it gives 208,827,064.576 seconds, about 6.62 years. Rate limits affect online guessing; salted adaptive hashing raises offline cost. Character policy cannot replace storage and access controls.

How exams test application and data security

Questions may ask for the violated CIA goal, authentication versus authorisation and audit, an attack-control match, a suitable cryptographic primitive, an access-control trace, or modular arithmetic.

If u17 is authenticated but lacks refund permission, denial is correct. If an attacker can replace both a message and its digest, the bare digest gives no trusted integrity; use a protected reference, MAC, or signature.

Use the Computer Networks subject map to connect these controls with the protocols and traffic they protect.

The short version and the next useful step

Identify the asset and required property. Place controls at transport, identity, policy, input, storage, and audit boundaries. Choose a primitive for its actual property, then trace a request. Redo Request B with refundAmount=7000: it fails because 7000 > 6400, although the finance role and 10000 ceiling pass.

GATE-focused readers can use GATE Guidance by Sanchit Sir. For a broader sequence including Computer Networks, use CS Fundamentals for Placements by Sanchit Sir.