Risks of using APIs

Tip: Choose Save as PDF in the print dialog to download. Use A4 paper size.

Risks of using APIs

Name:
Date:
Class:

Quick Questions

Shade in the A or B circle for each question.

1. An API endpoint returns customer records to anyone who sends a request, with no login or API key required. Which risk is this?
A Rate limiting, because the API is too fast
B Missing authentication, so attackers can call the API directly
2. A mobile app only needs a user's name, but the API sends back the full user record, including their address and date of birth. What is this called?
A Excessive data exposure
B Input validation
3. An API accepts a text field and passes it straight into a SQL query without checking it. Which control is missing?
A Input validation
B Rate limiting
4. An attacker uses a script to try 10,000 passwords a minute against a login API, and the API never blocks them. Which control would reduce this risk?
A Making the response data larger
B Rate limiting on requests
5. True or false: if the app's screen validates user input, the API behind it is safe and does not need its own validation.
A False
B True

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left columnRight column
1GET /api/users/42 AA rate limit that blocks a client sending too many requests, which stops brute-force and flooding attacks.
2if (requests > 100) { block() } BA request that returns user 42's record. With no authentication check, anyone who knows the URL could read it.
3Excessive data exposure: the API returns more fields than the app needs, so attackers can read sensitive data CThe request value is added to the query without validation, so an attacker can send SQL code and run an injection attack.
4Input validation: the API checks that data from a request is the expected type and format before using it Dreturn user; // includes password_hash and tfn
5app.get('/admin/export', exportAll) EThe admin endpoint has no authentication or authorisation check, so any attacker who finds the URL can download all the data.
6query = 'SELECT * FROM users WHERE id=' + id Fif (!Number.isInteger(id)) { reject() }

Definitions

API security risk

Fill in the Blanks

Complete each line of code by filling in the missing parts.

1.
IF caller is _____________ THEN SEND orderData END IF
2.
SELECT _ FROM users WHERE userId = 5
3.
if (______ qty !== "number") { return res.status(400); }
4.
IF requestCount _ maxRequests THEN RESPOND "429 Too Many Requests" END IF
5.
fetch("/api/orders", { headers: { _____________: apiKey } })

Spot the Error

Shade in the letter of the line that contains an error.

Question 1
A IF token IS NOT VALID THEN
B RETURN user.profile
C ELSE
D RETURN error 401
Question 2
A count ← requests from ip
B count ← count + 1
C IF count > 100 THEN
D RESET count to 0
E RETURN data
Question 3
A id ← request.userId
B IF id IS NOT A NUMBER THEN
C ACCEPT id and continue
D RETURN getUser(id)
Question 4
A user ← getUser(request.id)
B RETURN user.name, user.hash
C // password hash never sent
Question 5
A key ← request.apiKey
B valid ← checkKey(key)
C IF key EXISTS THEN
D RETURN report

Answer Key

Risks of using APIs
Section A: Quick Questions
Q1
B — Missing authentication, so attackers can call the API directly
Q2
A — Excessive data exposure
Q3
A — Input validation
Q4
B — Rate limiting on requests
Q5
A — False
Section B: Match the Pairs
Q1
GET /api/users/42 → A request that returns user 42's record. With no authentication check, anyone who knows the URL could read it.
Q2
if (requests > 100) { block() } → A rate limit that blocks a client sending too many requests, which stops brute-force and flooding attacks.
Q3
Excessive data exposure: the API returns more fields than the app needs, so attackers can read sensitive data → return user; // includes password_hash and tfn
Q4
Input validation: the API checks that data from a request is the expected type and format before using it → if (!Number.isInteger(id)) { reject() }
Q5
app.get('/admin/export', exportAll) → The admin endpoint has no authentication or authorisation check, so any attacker who finds the URL can download all the data.
Q6
query = 'SELECT * FROM users WHERE id=' + id → The request value is added to the query without validation, so an attacker can send SQL code and run an injection attack.
Section C: Definitions
Q1
API security risk — An API is risky when it lacks authentication, input validation or rate limits, so attackers can send requests straight to it and steal data or misuse it.
Section D: Fill in the Blanks
Q1
IF caller is authenticated THEN SEND orderData END IF
Q2
SELECT * FROM users WHERE userId = 5
Q3
if (typeof qty !== "number") { return res.status(400); }
Q4
IF requestCount > maxRequests THEN RESPOND "429 Too Many Requests" END IF
Q5
fetch("/api/orders", { headers: { Authorization: apiKey } })
Section E: Spot the Error
Q1
A — The condition is reversed, so the profile is returned only when the token is invalid. Valid users are refused and attackers get in. The check should be IF token IS VALID THEN.
Q2
D — Resetting the counter means the limit is never enforced, so an attacker can send unlimited requests. When the limit is passed the API should reject the request with RETURN error 429 (too many requests).
Q3
C — Input that fails validation must be rejected. Accepting it lets malformed or malicious data reach the system. It should be RETURN error 400 (bad request).
Q4
B — This is excessive data exposure. The API sends the password hash, which the client does not need and which contradicts the comment. It should return only the fields the app needs, such as user.name and user.email.
Q5
C — This is weak authentication. It only checks that some key was supplied, not that it is valid, so any made-up key gets the report. It should test the result of checkKey with IF valid = TRUE THEN.