All lessons Leer en español

Security in depth · Unit 28 · Lesson 9 of 11

Ask how a useful feature could cause harm

Turn a feature’s plausible unwanted outcome into a requirement that preserves its useful purpose.

4 minreadyShort lesson

Helpful before thisThreat modeling: ask before building

See all lessons in this topic

After this lesson you can

  • Connect an abuse case to a realistic actor, an exposed asset, and verifiable access requirements.

Keep the useful feature, then describe the unwanted outcome precisely.

Two views of the same feature

A user story describes a benefit for an intended actor. An abuse case examines how the same feature could cause harm under plausible conditions. Name the actor’s actual access, the asset, and the unwanted result; an actor with unlimited powers gives the designer little to work with.

Turn the concern into an observable requirement. A phrase such as “prevent misuse” is too vague to show what should be allowed or refused.

Useful feature → Plausible unwanted outcome → Design requirementUseful featurePlausible unwantedoutcomeDesign requirement
Connect a realistic unwanted outcome to a requirement and its acceptance evidence. The useful user story should still work.

Supplied record: the repair café

The fictional coordinator wants assigned helpers to open a roster from a convenient link. The design proposal contains:

Useful story: an assigned helper views their shift and teammates.
Data: names, shifts, and private contact numbers.
Approved audience: current assigned helpers only.
Proposed access rule: anyone holding the link can view the roster.
Sharing condition: recipients can forward messages containing the link.

Assume no identity or membership check exists elsewhere in this proposed flow. A recipient outside the helper group could receive the link and become an unintended reader. That condition follows from the design; it does not require guessing the link or administering the system.

Write the paired requirement

Require current helper authorization before displaying the roster, while keeping access straightforward for the approved group. Write one acceptance case for an assigned helper and another for a recipient outside that group.

A private label or difficult-to-guess address does not resolve forwarding. Also record the remaining boundary: this access rule cannot retract information already copied by an authorized reader. That separate sharing concern needs its own product decision.

Check yourself

No timer. No penalties. Read the explanation and try again whenever you like.

  1. Which requirement best addresses the roster scenario while preserving collaboration?

    Show the answer

    Correct answer: Authorize current assigned helpers before displaying the roster, even when they arrive through a forwarded link. The requirement checks the approved audience at access time and still allows the intended helpers to collaborate.

Try it

  • WriteWrite a paired user story and abuse case for the roster. Name the actor, condition, unwanted outcome, and requirement; add one approved-access case and one access-denied case.
References