Security Testing: the QA View

Fernway holds names, travel dates, and payment flows — exactly the data attackers want. Security testing asks a question unlike any other in this book: not "does it work for a user?" but "what can someone hostile make it do?" You are not a security specialist, and this page won't pretend to make you one. But testers find real vulnerabilities constantly — because probing for the unexpected is already the job, and the attacker's mindset is a short hop from the tester's. This is the QA view: what you'll genuinely catch, how to handle it, and where the specialists take over.

A hotel analogy sets the tone. An employee notices a guest key opens every room on the floor. They aren't a locksmith, and reporting it doesn't require locksmithing — it requires noticing, and knowing it's urgent and who to tell quietly. That's your role here, precisely.

The Attacker's Question

Reframe one thing you already know and the mindset clicks: every input is a door. Chapter 4's invalid partitions — the empty field, the oversized value, the wrong type — reread now as attack surface: what if the weird input isn't a confused traveler but a hostile one, crafting it on purpose? The tester's reflexive "what if I put something strange here?" is genuinely halfway to the security mindset. The other half is assuming the person at the keyboard wants to break in — and that reframe, applied to inputs you already test, surfaces a surprising amount.

The Classics, at Concept Level

Three household-name vulnerability classes, in plain words with a Fernway face — enough to recognize and route, not to exploit. Injection: input treated as commands instead of data — the search box that passes your text straight into a database query (Chapter 8's data layer, now under attack); type the right characters and you're speaking to the database directly. Broken access control: the app lets you reach things that aren't yours — and this one is the most QA-findable class, because it needs no tools, just curiosity about that number in the URL. Weak defaults: test accounts left enabled in production, admin passwords never changed, debug pages exposed — the unlocked doors nobody meant to leave open. The industry's canonical catalogue of these is the OWASP list — named here so you recognize it in postings and can read it yourself; it's the field's shared vocabulary, not a syllabus this page teaches.

What QA Realistically Contributes

Three things, all within reach. Noticing — the URL-number probe belongs in every tester's Chapter 4.6 catalog now: change an ID in the address bar and see if someone else's data appears. Routing — security findings get quiet tickets, restricted visibility, small audience: you don't demo a vulnerability in the sprint review (that's handing attackers a map); responsible disclosure at team scale means fixed-before-discussed. Asking the security question in reviews — Chapter 3's static testing, extended: "the story says travelers see their bookings — what stops them seeing others'?" A refinement question no story writes itself, and a place a non-specialist adds real security value before code exists.

What QA Does Not Do

The honest boundary, stated plainly so you neither overreach nor undervalue yourself. Penetration testing — professionals attacking a system with permission, deep and methodical — is a specialist craft. Security architecture — designing defenses — is not QA's table. Cryptography choices — which encryption, how keys are managed — belong to experts, and guessing there is dangerous. Name these with respect, not mystery: you contribute noticing, routing, and the review question; specialists contribute depth. The generalist who knows exactly where their contribution ends is more valuable than one who bluffs past it.

FW-411: the URL Swap

Testing booking modifications — Chapter 7's charter territory — you try something the catalog now demands: change the booking ID in the page's URL to a neighboring number. And Saltwater Lodge's booking for a complete stranger renders on your screen — their name, their dates, their stay. Broken access control, found with zero tools, in ten seconds, by a tester who'd never heard the term a week ago. This is a real, career-making junior moment — the kind of find people remember you for. What you do next is the professional part: not a normal ticket, not a standup mention, not a screenshot in the team chat. A restricted-visibility ticket to the right person (Nadia, the security lead if there is one), small audience, fixed before it's discussed anywhere public. Fernway's tracker gets its first security-tagged, access-controlled ticket, and you get the story you'll tell in interviews for years — a story whose punchline is as much the quiet handling as the find.

Two honest handoffs to close, both to existing courses: Security for Beginners is the from-zero book for the reader who wants the discipline itself, and CyberSecurity Deep Dive is the practitioner's path. This page gave you the QA-shaped slice; those give you the whole loaf.