Security Basics for Testers

A tester at a sports shop is checking the new “Order details” page. The address bar says shop.example.com/orders/1042. Out of curiosity, she changes it to /orders/1043 and presses Enter. The page loads, showing a different customer’s name, home address and the running shoes he bought last week.

Nobody hacked anything. She changed one number. That is one of the most common and most serious security bugs on the web, and a careful manual tester can find it in ten seconds.

This lesson shows you the basic security checks you can and should do as a manual tester, and how to do them safely and ethically.

Why it matters

Security bugs are different from most bugs. A broken button annoys users. A security bug can leak thousands of people’s addresses, card details or health data, lead to fines under privacy laws like GDPR, and destroy trust in a brand overnight.

And many of the worst leaks were not clever hacks. They were things like:

• an order page that showed any order if you changed the number,
• an admin page that was hidden from the menu but not actually protected,
• an API that sent the whole customer record to the browser, and the app just didn’t display most of it.

You don’t need to be a hacker to find those. You need to be curious, methodical and to know where to look. That’s security testingSecurity testingChecking that data and features are protected from unauthorized access and attacks.Open in glossary → at a tester’s level.

What you do vs what specialists do

The OWASP Top 10, as a map

OWASP (the Open Worldwide Application Security Project) is a non-profit that publishes the OWASP Top 10: a list of the most critical web application security risks, updated every few years (2017, 2021, 2025). Developers and security teams all over the world use it as a shared vocabulary.

You don’t need to memorize it. Use it as a map that tells you which areas deserve attention. Here are the categories where manual testers can contribute most (names from the 2025 list):

Authentication checks

AuthenticationAuthenticationChecking who a user is, usually with a password, a code or biometrics.Open in glossary → answers the question “who are you?”. Login is where most of these checks live, and the Login and Sign Up lesson covers it in depth. The security-focused checks are:

Authorization: broken access control

AuthorizationAuthorizationChecking what a logged-in user is allowed to see or do.Open in glossary → answers “what are you allowed to do?”. Bugs here are called broken access control, and they are the most common serious security bug on the web.

The key idea: the server must check permissions on every request. Hiding a button or a menu item is only cosmetic. If the server doesn’t check, anyone who types the right URL or sends the right request gets in.

Three checks you can do with two test accounts

Try it: the access-control lab

Below is a simulated test environment with two test users, Anna and Ben. Switch between the secure and the vulnerable version of the same shop and try all three checks. Notice how the vulnerable app looks exactly the same until you test it.

{
  "name": "Anna Novak"
}

Input handling

Every text field, search box, URL parameter and form is a door into the app. Good apps treat whatever comes through that door as plain data. Weak apps accidentally treat it as code, which leads to SQL injectionSQL injectionAn attack where text typed into a field is run as a database command.Open in glossary → and Cross-site scripting (XSS)Cross-site scripting (XSS)An attack where text a user enters is run as code in other people's browsers.Open in glossary →.

You don’t need attack payloads to spot the warning signs. Simple, harmless input is enough:

Sensitive data exposure

Sensitive data (passwords, tokens, card numbers, addresses, health data) should only travel where it’s needed and never be left lying around. Here’s where testers find it:

• In URLs. After logging in or submitting a form, look at the address bar. Passwords, tokens or personal data in the URL end up in browser history, server logs and analytics. A login form must use POST, not GET.
• In browser storage. Open DevTools › Application › Local Storage, Session Storage and Cookies. Passwords and card numbers should never be stored there. Long-lived tokens in local storageLocal storageBrowser storage where websites keep data that survives closing the tab, like settings or a cart.Open in glossary → are worth asking the team about.
• In API responses. Open DevTools › Network, click a request and look at the Response. The page may show only “Ben O.”, while the API returns Ben’s email, phone and address. If the browser receives it, anyone can read it.
• In error pages. A stack trace (lines like at OrderService.get (/srv/app/...)), a database error or a framework debug page tells attackers what technology you use and where it breaks.
• In emails and notifications. A “Welcome” email that contains your password in plain text means the password wasn’t stored safely (see password hashingPassword hashingStoring a one-way scrambled version of a password instead of the password itself.Open in glossary →).

HTTPS and mixed content

HTTPSHTTPSThe secure version of HTTP; traffic between the browser or app and the server is encrypted.Open in glossary → encrypts traffic between the browser and the server. On a modern site, every page should use it, not only login and checkout.

• Type the address with http://. You should be redirected to https://.
• Check the padlock in the address bar. A certificate warning in a test environment may be expected (ask), but never in production. See SSL certificateSSL certificateThe certificate that lets a browser or app verify a server's identity and encrypt traffic (HTTPS).Open in glossary →.
• Mixed content means an HTTPS page loads images, scripts or forms over plain HTTP. Browsers block or warn about it. Look in DevTools › Console for “Mixed Content” warnings.
• In DevTools › Application › Cookies, session cookies should have the Secure and HttpOnly flags ticked.

File uploads

Profile photos, receipts, CVs: upload features are a favorite target. Basic checks:

• Type limits. If only images are allowed, try a .pdf or .txt file. Then rename a text file to photo.jpg and try again. The server should check the real content, not just the name.
• Size limits. Upload a file just under and just over the documented limit (boundary value analysisBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary → applies here too). Over the limit should give a clear error, not a crash or a timeout.
• Odd file names. Very long names, spaces, emoji and characters like ' or < in the name.
• Where it ends up. Is an uploaded private document reachable by anyone who has the link? Try the link in a logged-out private window.

Rate limiting

rate limitingRate limitingCapping how many requests a user or device can make in a period of time.Open in glossary → caps how often something can be done. Without it, attackers can guess passwords, coupon codes or one-time codes by trying thousands of times.

Check the features where repetition is dangerous: login, “Send code again” for SMS or email, password reset, coupon or gift-card fields, sign-up. Repeat the action 10–20 times quickly. Good apps slow you down, show “Too many attempts, try again in 5 minutes” or return the HTTP status 429 Too Many Requests.

What to test

Access control: change IDs in URLs and API calls between two test users · open admin and other users’ pages as a customer · try actions on items that are not yours (edit, cancel, delete) · check that hidden or disabled buttons are also blocked by the server.

Authentication and sessions: lockout after repeated failures · identical error messages for wrong email and wrong password · logout invalidates the session (Back button, second tab) · session expires after the agreed idle time · password reset links expire and are single use.

Input: apostrophes and quotes in every field · harmless markup like <b>test</b> in anything that is shown to other users (reviews, names, comments, chat) · very long input · special characters in URL parameters.

Data exposure: URL after login and form submissions · Local Storage, Session Storage and cookies · API responses in the Network tab · error pages and 404 pages · emails and notifications.

Transport, uploads and limits: HTTPS redirect and mixed content · file type, size and name checks · rate limits on login, codes and coupons.

Common security bugs

Find the bug

This is a vulnerable test build of a small sports shop. It runs entirely in your browser with fake test data, so explore freely. Log in with the test account shown on the page, then:

• Watch the address bar and the DevTools · Network panel (click a request to see its response).
• Open your orders, then try other order numbers.
• Search for something with an apostrophe, like runner's.
• Write a review with harmless markup.
• Try URLs that a customer shouldn’t reach.

Reporting security bugs responsibly

A security bug report is different from a normal bug reportBug reportA clear written description of a bug so developers can reproduce and fix it.Open in glossary →. The goal is to get it fixed without spreading the details.

Tools & how-to

Example test cases

Checklist

Check your understanding