Skip to content
Kodesec × Integrated-Systems.ai
KODESEC
Book a call

A06 · OWASP Top 10 · 3 min

Insecure design. A perfect build of a flawed blueprint.

Nothing is coded wrong. The plan never asked "how could someone abuse this?", so no amount of careful programming fixes it later.

I run a

In 10 seconds

A feature that works, with no limits planned.

What it is

A flaw in how a feature was planned, not how it was coded. The code does exactly what the plan says. The plan just never imagined misuse, like unlimited coupons or unlimited password guesses.

Why you care

Scanners and code reviews miss it, because nothing is broken. Attackers simply use your own features in ways nobody planned, and it can cost you free goods, endless refunds and drained stock.

What to do

Have "what could go wrong?" asked before building, not after launch. The rules and limits are business decisions, so this is where owners matter most.

For your business

What's at stake for you.

I run a

Who is affected

Your customers, and anyone who trusts you with their details.

What it could cost

Free goods, endless refunds and drained stock.

Ask this first

“What limits stop one person using offers repeatedly, and who set those rules?”

Where it hides

Pick a feature and ask "what if someone...?"

Every feature that handles money, access or stock needs limits in the plan.

yourbusiness.com/checkout?coupon=...
What's here
Promo codes, loyalty points, referral rewards and free trials.
What goes wrong
No limit on how often a code is used, stacked or shared, so a welcome offer is claimed thousands of times.
Ask your team
What stops one person using an offer many times or stacking several? Who set those rules?
Developers call it
Business logic abuse, missing limits

What it costs

Real losses, from features working as planned.

Direct losses

Free goods, endless refunds, drained stock: real money, through your own features.

Invisible to tools

Nothing is broken, so scanners and code reviews stay quiet. You find out from the bill or the customers.

Costly to fix late

Changing a plan after launch means rework across the product. Adding the limits at design time usually costs far less.

Your name

When bots empty your stock or a promo is abused, customers blame you, not the attacker.

For an online shop: a feature planned without limits could lead to free goods, endless refunds and drained stock.

Does this apply to you?

Tick what's true. Get your questions.

First

So the questions fit you

What kind of business do you run?

Real cases

Features that worked, exactly as designed.

Missing limits, 2021 to 2022

A lookup feature with no brakes.

What it cost
In November 2022, Ireland's Data Protection Commission fined Meta €265 million, finding it hadn't built adequate data-protection safeguards into the feature by design and by default.
The lesson
Nothing was hacked. The feature worked as planned, with no limit on how fast or how often it could be used.
Read the full story and sources

Facebook let people find others by phone number through a contact-import feature. Attackers automated it, trying huge numbers of phone numbers and collecting profile details. Data on about 533 million users, including phone numbers, was shared online in April 2021. Meta said the scraping happened before September 2019 and that the issue had since been fixed.

In November 2022, Ireland's Data Protection Commission fined Meta €265 million, finding it hadn't built adequate data-protection safeguards into the feature by design and by default.

Sources: Irish Data Protection Commission (November 2022), Meta statements, press coverage.

Your part

Three decisions that are yours.

  1. 01Set the rulesFor every flow that moves money, stock or data, decide the limits: how often, how much, and who approves. These are business rules, so they're yours.
  2. 02Ask "what could go wrong?" firstRequire a short abuse review before any new feature is built, with someone playing the attacker.
  3. 03Put it in the plan, then test itWrite security requirements into the specification, and have the finished feature tested against abuse, not just against bugs.
For your developer: the technical layer
  • Threat-model each feature early (data-flow diagrams, STRIDE) and write abuse cases next to user stories.
  • Enforce business limits on the server: rate limits, quotas, per-user and per-device caps, velocity checks.
  • Never trust the client for prices, roles or state. Recompute them server-side.
  • Apply least privilege, and require a second approval (two-person rule) for high-risk actions.
  • Write tests that assert abuse fails, such as the 501st use of a coupon being rejected.
  • Add bot defences on high-value flows, monitor for abnormal usage, and keep a kill switch.
  • Reuse proven design patterns and reference architectures instead of inventing security-critical flows.

Remember

Three things to keep.

  • Perfect code can't fix a plan that never imagined abuse.
  • Limits, approvals and who can do what are business decisions. Make them early.
  • Ask "what could go wrong?" before building, not after launch.

What OWASP says

The essentials, slide by slide.

A06 · owasp top 10 · 01/04

OWASP Top 10 · A06

insecure design

Source: OWASP Top 10:2025 (CC BY 3.0) ↗

OWASP is a non-profit that publishes the industry's standard list of web risks. Safety measures adapted from the OWASP Top 10:2025 (CC BY 3.0). The people and businesses in the examples are made up.