Home/ Grad/ Learning
Grad Level · Learn by Doing

Security Testing Basics

Security bugs are not exotic. They are everywhere. Learn to spot SQL injection, XSS, broken authentication, and exposed data — without tools, just careful manual testing.

Grad ~12 min read

The Hook — The Data Breach Nobody Tested

A NZ healthcare provider launched a patient portal. A tester noticed that changing the URL from /patient/123 to /patient/124 showed another patient's medical records. No authentication check. The team said "that's a bug for the developer." The security team didn't catch it. It shipped. Within weeks, a journalist logged in as patient 1, downloaded all 50,000 patient records, and published them. The story made national news.

This is not a rare exploit. This is an access control bug — one of the OWASP Top 10 most common security failures. A QA tester would have found it in 30 seconds by changing a URL parameter.

The Rule

Security testing is investigating whether the app protects user data, prevents unauthorized access, and resists common attacks. You are testing like an attacker, not like a user following happy-path workflows.

A security tester asks: "What if I do the wrong thing? What if I cheat? What happens?"

  • What if I submit SQL instead of a username?
  • What if I change a URL parameter to access someone else's data?
  • What if I put a script tag in a comment?
  • What if I try to log in as admin with a blank password?
  • What if I intercept the request and modify the price before sending it?

OWASP Top 3 Vulnerabilities (for Testers)

1. Broken Access Control (IDOR)

What it is: Users can access data they shouldn't. Changing a URL ID or parameter reveals another user's information.

Example: /profile/123 shows your profile. Change it to /profile/999 and see someone else's.

How to test:

  • Log in as user A. View your profile URL: /profile/123
  • Log in as user B in a different browser or incognito tab. Note their profile URL: /profile/456
  • Go back to user A's browser. Manually change the URL to /profile/456
  • If you see user B's profile, that's a critical bug. This is IDOR (Insecure Direct Object Reference)

NZ impact: If a banking app has IDOR, attackers can see all account balances for all customers by looping through user IDs.

2. SQL Injection

What it is: Submitting SQL code in a form field tricks the database into executing malicious queries.

Example: Username field says "Enter your username." You type: admin' --

This can bypass login: the SQL becomes SELECT * FROM users WHERE username='admin'--' (the -- comments out the password check).

How to test:

  • Find any form input: login, search, feedback, etc.
  • Try injecting SQL keywords: ' OR '1'='1
  • Try comment syntax: admin' --
  • Try union queries: ' UNION SELECT username, password FROM users --
  • If the app returns unexpected data or errors, you may have found SQL injection

Signs of vulnerability: Database error messages visible to the user, unexpected data returned, login bypassed.

3. Cross-Site Scripting (XSS)

What it is: Injecting JavaScript code into the app so it runs in other users' browsers.

Example: A comment field accepts <script>alert('hacked')</script>. When another user views the comment, the script runs.

How to test:

  • Find any user input field: comment, profile, bio, feedback, etc.
  • Try entering HTML tags: <h1>test</h1>
  • Try JavaScript: <script>alert('XSS')</script>
  • Try img tags: <img src=x onerror="alert('XSS')">
  • Submit the input and reload the page
  • If the HTML/JavaScript renders instead of being escaped, that's XSS

Impact: An attacker can steal session cookies, redirect users, or phish for passwords.

Security Testing Checklist

Authentication & Access

  • ☐ Can I log in with a blank username and password?
  • ☐ Can I reset someone else's password knowing only their email?
  • ☐ If I change the URL ID (e.g., /user/123 → /user/999), can I see another user's data?
  • ☐ Can I remain logged in after changing my own password?
  • ☐ Can I access admin pages if I'm logged in as a regular user?

Data Exposure

  • ☐ Are passwords stored in plain text in the form? (Check HTML source)
  • ☐ Are API responses unencrypted? (Check Network tab)
  • ☐ Are sensitive fields (email, SSN, card number) visible in URLs or form hidden fields?
  • ☐ Does the page cache sensitive data? (Check browser cache)

Input Validation

  • ☐ Can I submit SQL keywords: ' OR '1'='1
  • ☐ Can I submit HTML tags: <h1>
  • ☐ Can I submit JavaScript: <script>
  • ☐ Can I submit very long strings (buffer overflow)?
  • ☐ Can I submit special characters: ; : \ / " ' --

Using DevTools to Spot Bugs

Check the HTML source (Ctrl+U or right-click → View Page Source):

  • Look for <input type="password" value="mypassword"> — password hardcoded in HTML. Critical bug.
  • Look for <input type="hidden" name="price" value="100"> — price hardcoded. An attacker can change it.
  • Look for comments with secrets: <!-- TODO: remove test admin account -->

Check the Network tab (F12 → Network):

  • Click a request and check the Response tab. Is sensitive data visible in plain text?
  • Check if the connection is HTTPS (secure) or HTTP (unencrypted). Never HTTP for login.
  • Look at the URL parameters. Is the API key visible? /api/data?key=abc123 is exposed.

Common Mistakes

❌ Only Testing the Happy Path

Security bugs only appear when you try to break the app. A tester who only tests valid inputs will never find SQL injection or access control bugs.

❌ Assuming the App Validates Because You Tested One Field

Just because the login field validates doesn't mean the comment field does. Test every input field independently.

❌ Not Checking URLs and Hidden Fields

Some of the easiest bugs to find: change a URL ID, or inspect a hidden form field that contains the price. Don't just test visible inputs.

❌ Not Reporting Security Bugs

If you find a security bug, report it immediately and privately. Do not post it on social media or tell colleagues casually. Notify the security team directly.

Self-Check

  1. You notice the URL shows /customer/789. You change it to /customer/790 and see another customer's data. What is this called?
    IDOR (Insecure Direct Object Reference). It's broken access control. Critical security bug.
  2. In a search box, you try entering: ' OR '1'='1. The search returns all records. What happened?
    SQL injection. The input was not escaped, so your SQL was executed directly on the database. Critical bug.
  3. In a comment field, you post: <script>alert('hack')</script>. Every user who views the comment sees the alert. What is this?
    Cross-Site Scripting (XSS). The script runs in every user's browser. Critical bug.
  4. You find the login form has a hidden field: <input type="hidden" name="role" value="admin">. Is this a security issue?
    Yes. An attacker can change the value to "admin" before submitting, potentially gaining unauthorized access.
  5. The page loads over HTTP (not HTTPS). Is this a security issue?
    Yes. All data sent over HTTP is unencrypted. Anyone on the network can intercept passwords and session tokens.