Software QA / Advanced: strategy, resilience, and leadership / Lesson 14
Security quality and abuse-case testing
Translate trust boundaries into defensive checks using synthetic users and owned resources. Focus on authorization, input handling, business abuse, and trustworthy security evidence within an authorized lab.
On this page
Lesson goals
- Build security cases from assets and trust boundaries.
- Test horizontal and vertical authorization.
- Distinguish local evidence from a complete security assessment.
Ask who should control each asset
Identify assets such as learner records, refund authority, scholarship balances, and session credentials. Mark where data crosses a trust boundary: browser to service, service to database, or organization to external provider. For each boundary, ask how identity is established, permission checked, input constrained, and failure communicated. Ordinary functional cases assume cooperative users; abuse cases challenge those assumptions. Keep security testing within explicitly authorized systems and synthetic data. This chapter’s examples describe controlled checks, with no scanning or load against live services and no assumption that a checklist proves security.
Worked case: two owners and one administrator
Create learner A, learner B, and an administrator in an isolated fixture. A owns enrollment EA; B owns EB. Verify A can read EA, then request EB as A using its synthetic identifier. Expect the agreed denial and no private fields. Next request an administrator-only refund action as A and expect rejection with no financial side effect. Include allowed administrator behavior as a positive control. Hiding a button is insufficient because a client can construct a request directly; enforcement belongs at the server boundary.
Actor | Resource/action | Expected
A | read EA | permitted; only allowed fields
A | read EB | denied; no B data
A | approve refund | denied; balance unchanged
Administrator | approved scoped refund | permitted; one audited effectDifferent owners test horizontal isolation; privileged actions test vertical boundaries.
Inputs need context-aware handling
Validate business shape at the service boundary and use safe mechanisms for the output context. Parameterized queries address a different risk from HTML output escaping; one is not a replacement for the other. In a controlled fixture, use a name containing apostrophes and markup-like text. Expect it to be handled as data, preserved or normalized according to the rule, and displayed without becoming executable markup. Also inspect error responses for internal paths or stack traces. Avoid a single “sanitization” claim that hides which input and output contexts were actually evaluated.
Worked case: duplicate benefit claims
A scholarship can be redeemed once per year. Submit a legitimate claim, then repeat it from a second authenticated session for the same synthetic learner. Expect the existing result or an agreed duplicate denial, with only one grant. Add a controlled overlap at the service boundary if concurrency is in scope. This is a business-abuse case even though every request is well-formed and authenticated. Inspect the balance and audit trail, because a denial shown to the user can still conceal an unintended write. Keep test counts bounded and do not test rate limits by flooding shared services.
Report security findings precisely
A useful finding names the asset, actor, precondition, unauthorized effect, evidence, and proposed control. Preserve reproduction in a private controlled context and sanitize tokens and personal data. Confirm a fix with the original case, adjacent roles, alternate entry points, and an allowed operation to detect over-restrictive repairs. OWASP provides testing guidance, but application-specific threat modeling and expert assessment may reveal risks beyond the selected cases. Report tested boundaries and unresolved areas; do not turn a passing scanner or a small permission matrix into a guarantee of absence of vulnerabilities.
Common errors and fixes
UI hiding is mistaken for authorization
- Why it happens
- The server accepts actions the page merely conceals.
- How to fix it
- Enforce and test permission at each server entry point.
- Prevent it next time
- Maintain an actor/action/object matrix.
Only anonymous attacks are considered
- Why it happens
- Authenticated users are assumed trustworthy for all objects.
- How to fix it
- Test another owner’s object and privileged actions with valid accounts.
- Prevent it next time
- Include horizontal and vertical cases in security acceptance.
A scanner result is called a security guarantee
- Why it happens
- Detectable patterns are confused with all threats.
- How to fix it
- State scope and supplement with threat-driven manual checks.
- Prevent it next time
- Review residual security risk with accountable specialists.
Check your understanding
1. A learner cannot see the refund button. What must still be tested?
Show worked solution
Send the refund action as that learner in an authorized lab with a valid synthetic enrollment. Expect server-side denial, unchanged balance, and no refund record. Then perform the permitted administrator case to ensure the control does not block legitimate work. UI absence alone gives no server authorization evidence.
2. A repeated scholarship request returns an error but balance rises twice. How do you classify it?
Show worked solution
It is a duplicate-effect business-logic failure despite an apparently correct error response. Record both request results, the two persisted effects, and the once-per-year oracle. Repair atomicity or idempotency as appropriate, then confirm one effect under sequential and controlled concurrent repeats.
Key takeaways
- Authentication does not establish permission for every object or action.
- Security evidence must include effects, allowed controls, and explicit scope.