Module 75: Web App Security

Why each option is right or wrong

• “Weak passwords chosen by users” (Incorrect): Authentication failures are on the list, but access control ranks higher.
• “Injection, such as SQL injection” (Incorrect): Injection is still on the list, but broken access control ranks first now.
• “Security misconfiguration of servers” (Incorrect): Misconfiguration is on the list, but broken access control is more common.
• “Broken access control” is correct.

  In OWASP's recent lists, broken access control comes first: users reaching data or actions they shouldn't, through missing checks, changed ids or forced browsing. It's common because every route needs its own check.

  • Examples: IDOR, missing role checks, editing others' records.
  • Fix: server-side checks on every request, tested for every role.

📖 Revise: Lesson 1: The OWASP Top 10

Why each option is right or wrong

• “On any public website, if you don't change anything” (Incorrect): Testing without permission can be illegal even without changes.
• “On a friend's website, as long as you tell them afterwards” (Incorrect): Permission must come before testing, not after.
• “On large company sites, since they can easily afford any risk” (Incorrect): Size doesn't grant permission.
• “Only on your own apps or deliberately vulnerable training apps” is correct.

  Attacking systems without permission is illegal and can cause real harm. Practice apps like OWASP Juice Shop are built to be attacked safely on your own machine.

  • Run locally: in Docker or a VM.
  • Real systems: only with written permission.

📖 Revise: Lesson 1: The OWASP Top 10

Why each option is right or wrong

• “Removing quote marks and semicolons from every user input” (Incorrect): Filtering characters is easy to get wrong and bypass.
• “Hiding the database's address from visitors to the site” (Incorrect): Hiding helps a little, but injection comes through your app.
• “Using HTTPS on every page” (Incorrect): HTTPS protects data in transit, not how queries are built.
• “Parameterised queries, so input is treated as data” is correct.

  With parameters, the SQL and the values travel separately. The database doesn't interpret user input as SQL, so ' OR 1=1 -- is just odd text, not a command.

  • Example: db.query("SELECT * FROM users WHERE email = $1", [email]).
  • ORMs: usually parameterise for you.

📖 Revise: Lesson 2: SQL injection

Why each option is right or wrong

• “Pass it as a ? parameter like any other value” (Incorrect): Parameters are for values, not column names.
• “Put quotes around whatever the user sends” (Incorrect): Quoting doesn't make arbitrary input safe.
• “Let users type any column name they like” (Incorrect): That invites injection and data leaks.
• “Check it against an allow-list of column names” is correct.

  Column names can't be sent as parameters, so they must be built into the SQL. Mapping the user's choice to one of a few known names, and rejecting anything else, keeps attackers from injecting SQL or sorting by private columns.

  • Example: { newest: "created_at", name: "name" }.
  • Unknown value: return 400.

📖 Revise: Lesson 2: SQL injection

Why each option is right or wrong

• “React removes all JavaScript from the page” (Incorrect): React is JavaScript; it escapes user values instead.
• “Browsers block all inline scripts on sites built with React” (Incorrect): Browsers don't treat React sites specially.
• “React encrypts every value before it displays it on screen” (Incorrect): Escaping isn't encryption.
• “It escapes values in JSX, so input is shown as text” is correct.

  When you write {comment} in JSX, React converts special characters, so <script> appears as text rather than running. The danger returns with dangerouslySetInnerHTML or unchecked URLs.

  • Avoid: dangerouslySetInnerHTML with user content.
  • Check: links users supply, like javascript: URLs.

📖 Revise: Lesson 3: Cross-site scripting (XSS)

Why each option is right or wrong

• “Encrypts the page's content before it leaves the server” (Incorrect): CSP restricts sources; HTTPS encrypts.
• “Hides the site from search engines and automated scanners” (Incorrect): CSP is about which content runs, not search.
• “Checks that every user's password is strong enough” (Incorrect): Password checks are separate.
• “Tells the browser which scripts may run” is correct.

  A CSP header lists trusted sources for scripts, styles and other content. If an attacker injects a script from elsewhere, or inline, the browser refuses to run it, adding a strong second layer against XSS.

  • Start with: report-only mode to find what would break.
  • Avoid: unsafe-inline where possible.

📖 Revise: Lesson 3: Cross-site scripting (XSS)

Why each option is right or wrong

• “Attackers steal the saved passwords from the victim's browser” (Incorrect): CSRF doesn't need the password; it uses the existing session.
• “Any website can read other websites' cookies whenever it likes” (Incorrect): They can't read them; the browser just sends them.
• “HTTPS is switched off on most sites that use cookies” (Incorrect): CSRF works over HTTPS too.
• “Browsers attach a site's cookies even when another site triggers the request” is correct.

  If you're signed in to your bank and visit a malicious page, it can make your browser send a request to the bank. The browser adds the bank's cookies, so the request looks like it came from you.

  • Defences: SameSite cookies, CSRF tokens, checking the Origin header.
  • Most at risk: cookie-based sessions.

📖 Revise: Lesson 4: Cross-site request forgery (CSRF)

Why each option is right or wrong

• “HttpOnly” (Incorrect): HttpOnly stops JavaScript reading the cookie, not cross-site sending.
• “Secure” (Incorrect): Secure limits the cookie to HTTPS, not cross-site use.
• “Max-Age=0” (Incorrect): That deletes the cookie, which also ends the session.
• “SameSite=Lax or Strict” is correct.

  SameSite tells the browser not to send the cookie on requests started by other sites. With Lax, cross-site forms and background requests don't carry it, which blocks most CSRF while normal links still work.

  • Strict: doesn't send the cookie cross-site, even on links.
  • Still add: CSRF tokens for extra safety on sensitive actions.

📖 Revise: Lesson 4: Cross-site request forgery (CSRF)

Why each option is right or wrong

• “Stack traces make error pages load too slowly for users” (Incorrect): Speed isn't the main concern; exposure is.
• “Every hosting provider requires them to be hidden” (Incorrect): It's good security practice, not a hosting rule.
• “Stack traces only appear when the whole server crashes” (Incorrect): They appear on many errors; the issue is what they reveal.
• “They reveal internal details that help attackers” is correct.

  A stack trace shows file paths, library versions and sometimes data or queries. That tells an attacker what software you run and where to look for weaknesses. Log the details privately and show users a short message.

  • Production: generic message plus a reference id.
  • Development: full details are fine locally.

📖 Revise: Lesson 5: Misconfiguration

Why each option is right or wrong

• “Hides the server's software version” (Incorrect): That's done by removing headers like Server.
• “Speeds up the site by caching pages in the browser” (Incorrect): HSTS is about HTTPS, not caching.
• “Blocks visitors arriving from other countries” (Incorrect): It doesn't block anyone by location.
• “Tells browsers to use only HTTPS for the site” is correct.

  After seeing Strict-Transport-Security, the browser upgrades every future visit to HTTPS automatically, even if someone types http://. That blocks attacks that try to downgrade a visitor to plain HTTP.

  • Example: Strict-Transport-Security: max-age=31536000; includeSubDomains.
  • Make sure: HTTPS works everywhere first.

📖 Revise: Lesson 5: Misconfiguration