Module 76: API and Network Security

Why each option is right or wrong

• “The host firewall makes the cloud firewall unnecessary once it's set up” (Incorrect): Either one alone is a single point of failure; the value is in having both.
• “Cloud firewalls only filter traffic between data centres” (Incorrect): They filter traffic to your server; the point is having a second layer.
• “The cloud firewall handles web traffic and the host firewall handles SSH only” (Incorrect): Both can filter any port; they're overlapping layers, not a split of duties.
• “If one is misconfigured, the other still blocks traffic” is correct.

  A cloud firewall filters traffic before it reaches the server; a host firewall like UFW filters on the server itself. A mistake in one, such as an accidentally opened port, is still caught by the other.

  • Defence in depth: two independent layers.
  • Keep rules matched: only 22, 80 and 443 open, for example.

📖 Revise: Lesson 1: Firewalls and network layers

Why each option is right or wrong

• “Yes, a WAF blocks every possible attack automatically” (Incorrect): WAFs miss many attacks, especially logic and permission flaws.
• “Yes, as long as it's the most expensive plan” (Incorrect): Price doesn't make a WAF understand your app.
• “No, because WAFs make the site unreachable” (Incorrect): A WAF sits in front of a working site; it doesn't take it offline.
• “No, it's an extra layer; the app must still be secure” is correct.

  A web application firewall blocks common attack patterns, but attackers find ways around its rules, and it can't understand your app's permissions. It buys time; the real fix is in the code.

  • Good for: blocking known bad traffic and bots.
  • Can't fix: broken access control or logic flaws.

📖 Revise: Lesson 1: Firewalls and network layers

Why each option is right or wrong

• “It makes HTTPS connections slower” (Incorrect): Speed is barely affected; the danger is impersonation.
• “It stops the app from connecting at all” (Incorrect): It lets connections succeed, even to impostors.
• “It only matters for sites that take card payments” (Incorrect): Any traffic, such as sign-ins, API keys and personal data, can be read or changed.
• “An attacker in the middle could read or change traffic” is correct.

  Verification checks that the server really is who it claims. Without it, anyone between you and the server, on Wi-Fi or a compromised network, can present a fake certificate, decrypt the traffic and alter it.

  • Common bad fix: rejectUnauthorized: false or NODE_TLS_REJECT_UNAUTHORIZED=0.
  • Right fix: install the correct certificate or CA.

📖 Revise: Lesson 2: TLS everywhere

Why each option is right or wrong

• “Yes, every connection needs TLS, even inside one machine” (Incorrect): Encrypting loopback traffic adds little; the network risk isn't there.
• “No, because 127.0.0.1 traffic is already encrypted by Nginx” (Incorrect): Nginx decrypts HTTPS and forwards plain HTTP locally; it's safe because it stays on the machine.
• “Yes, otherwise Nginx can't forward requests” (Incorrect): Nginx forwards plain HTTP to local apps routinely.
• “Usually not, because it doesn't leave the server” is correct.

  Traffic to 127.0.0.1 stays inside the machine, so nobody on the network can see it. Encrypting it adds work without much benefit. Traffic between separate servers, even in a private network, is a different case.

  • Between machines: use TLS, or a private encrypted network.
  • Strict environments: may still require it everywhere.

📖 Revise: Lesson 2: TLS everywhere

Why each option is right or wrong

• “URLs are encrypted less strongly than headers over HTTPS” (Incorrect): Over HTTPS the whole request is encrypted; the issue is that URLs get saved in logs and history.
• “Keys in URLs make requests slower” (Incorrect): Speed isn't the issue; exposure is.
• “Keys in URLs stop the API from caching responses” (Incorrect): Caching isn't the concern; URLs end up in logs, browser history and shared links.
• “URLs end up in logs, history and proxies” is correct.

  Servers, proxies and browsers record full URLs in logs and history, and they may be shared in screenshots or links. A key in the URL spreads to all those places. Send keys in a header like Authorization instead.

  • Header example: Authorization: Bearer <key>.
  • If a key leaks: rotate it.

📖 Revise: Lesson 3: API authentication

Why each option is right or wrong

• “Check that the request uses HTTPS” (Incorrect): HTTPS protects the connection; anyone can send HTTPS requests.
• “Check the sender's IP address only” (Incorrect): IPs can change and some can be spoofed; signatures are stronger.
• “Trust it if the JSON looks correct” (Incorrect): Attackers can send perfectly formatted fake events.
• “Check its signature with the shared secret, and its timestamp” is correct.

  The sender signs the body with a secret only you and they know. Recomputing the signature proves the sender and that the body wasn't changed. Checking the timestamp rejects old requests replayed later.

  • Compare safely: a constant-time comparison.
  • Reject: missing or invalid signatures with 401.

📖 Revise: Lesson 3: API authentication

Why each option is right or wrong

• “403 Forbidden” (Incorrect): 403 means not allowed at all, not too many requests.
• “500 Internal Server Error” (Incorrect): Nothing failed on the server; it's limiting deliberately.
• “404 Not Found” (Incorrect): The resource exists; the client is just going too fast.
• “429 Too Many Requests” is correct.

  429 tells the client it has sent too many requests. Adding a Retry-After header says when to try again, so well-behaved clients back off.

  • Clients: should wait and retry with growing delays.
  • Log: repeated 429s to spot abuse.

📖 Revise: Lesson 4: Rate limits and abuse

Why each option is right or wrong

• “Login requests use more bandwidth than others” (Incorrect): Bandwidth isn't the reason; guessing attacks are.
• “Login responses contain more data than other API calls” (Incorrect): Response size isn't the reason; attackers repeat sign-in attempts to guess passwords.
• “Login pages are the slowest pages to load” (Incorrect): Speed isn't the reason for stricter limits.
• “It's the target of password guessing” is correct.

  Attackers try thousands of passwords against sign-in. Tight limits per account and per IP make guessing slow and noisy, while normal users rarely notice.

  • Also strict: password reset, sign-up, OTP verification.
  • Plus: MFA so a guessed password isn't enough.

📖 Revise: Lesson 4: Rate limits and abuse

Why each option is right or wrong

• “A rule that limits how many requests a server accepts” (Incorrect): That's rate limiting; SSRF is an attack that abuses server-side fetching.
• “Sending too many requests to slow a server down” (Incorrect): That's denial of service, not SSRF.
• “Stealing a user's session cookie with a script” (Incorrect): That's XSS-based session theft.
• “Tricking a server into requesting internal addresses for an attacker” is correct.

  If your app fetches URLs that users supply, such as for link previews, an attacker can give an internal address like a cloud metadata endpoint. Your server fetches it from inside the network and may hand back secrets.

  • Defence: allow-list domains, block private and metadata IPs.
  • Cloud: use metadata protections like IMDSv2.

📖 Revise: Lesson 5: Secure networks and server-side requests

Why each option is right or wrong

• “Admin panels load too slowly over the internet” (Incorrect): Speed isn't the reason; exposure is.
• “Search engines penalise sites with admin panels” (Incorrect): Search ranking isn't the concern.
• “Admin panels can't use HTTPS when they're public” (Incorrect): They can use HTTPS; the issue is that attackers can reach them.
• “They're powerful targets; a VPN removes them from the attack surface” is correct.

  An admin panel can change everything, so attackers look for it and try passwords against it. Putting it behind a VPN, or restricting it to known IPs, means attackers can't reach it at all.

  • Plus: MFA for admin accounts.
  • Log: every admin action.

📖 Revise: Lesson 5: Secure networks and server-side requests