← VCE Software Development U4O2

Risks of using APIs

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.

Part of: VCE Software Development - U4O2 - Cyber Security: secure software development practices — Module 25

Understanding Risks of using APIs in VCE Software Development U4O2

What it does: Returning the whole user object exposes private fields. The API should return only the fields the client actually needs. Checking that id is an integer before using it stops malformed or malicious input from reaching the database. Without authentication the API cannot tell who is asking, so any attacker who finds the endpoint can request data straight from it. Excessive data exposure means an API returns more data than the client needs. Attackers can read the extra data in the response even if the app hides it. Without input validation, an attacker can send malicious input such as SQL injection directly to the API and bypass the app's own interface.

Common mistakes: 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. 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).

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add Risks of using APIs to a class →

This module's key terms are also in a printable crossword (Modules 23–47) and word search (Modules 1–47).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
An API endpoint returns customer records to anyone who sends a request, with no login or API key required. Which risk is this?
Rate limiting, because the API is too fastMissing authentication, so attackers can call the API directly
Matches
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.
Applying
Meanings
Term
API security risk
Meaning
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.
Practice
IF apiKey is not valid THEN
Testing
Gaps
IF caller is THEN
Check Answer
Spots
1IF token IS NOT VALID THEN
2 RETURN user.profile

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Nebula Cat' badge — Orbit Debugger, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

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 ✓
Without authentication the API cannot tell who is asking, so any attacker who finds the endpoint can request data straight from it.
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
Excessive data exposure means an API returns more data than the client needs. Attackers can read the extra data in the response even if the app hides it.
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
Without input validation, an attacker can send malicious input such as SQL injection directly to the API and bypass the app's own interface.
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 ✓
Rate limiting restricts how many requests a client can make in a set time, which slows brute force attacks and stops the API being overwhelmed.
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
Attackers can skip the app and send requests directly to the API, so the API must validate input itself.

Match the Pairs

GET /api/users/42 → A request that returns user 42's record. With no authentication check, anyone who knows the URL could read it.
if (requests > 100) { block() } → A rate limit that blocks a client sending too many requests, which stops brute-force and flooding attacks.
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
Input validation: the API checks that data from a request is the expected type and format before using it → if (!Number.isInteger(id)) { reject() }
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.
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.

Key Term

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.

Fill in the Blanks

1. IF caller is authenticated THEN SEND orderData END IF
Hint: Type the word describing a caller whose identity has been verified before the API sends any data.
2. SELECT * FROM users WHERE userId = 5
Hint: Type the wildcard symbol that returns every column, which can cause excessive data exposure.
3. if (typeof qty !== "number") { return res.status(400); }
Hint: Type the operator that checks the data type of the input, so bad data is rejected.
4. IF requestCount > maxRequests THEN RESPOND "429 Too Many Requests" END IF
Hint: Type the comparison operator that detects when a client has gone over its rate limit.
5. fetch("/api/orders", { headers: { Authorization: apiKey } })
Hint: Type the HTTP header name that carries the caller's credentials to the API.

Spot the Error

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

Student with a class code? Join your class →