This is what the submission says about "Insecure Design"

> A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to "move left" as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures.

Seems pretty clear it's about upfront security thinking, planning and education. Of course all of these items in the list are gonna be general as they are categories, not specific line items.

I interpreted that one (perhaps too charitably) as being about business logic flaws, design decisions that are inherently dangerous, that sort of thing.

i.e. most of the other things on the list are issues that were introduced unintentionally, and this one is about decisions made by designers and developers that were themselves the problem.

Yup this is what I read, and covers a lot of security reviews I have come across, where someone requests some functioanlity, such as password recovery, or some promotional code, and someone else discovers how it can be exploited.

I'd say long overdue.

Some examples.

1. Providing a permission based check to prevent a user from accessing a specific UI page but then failing to secure the back-end API endpoint that supports the UI.

A developer implementing a user story reads the following acceptance criteria, "User without permission X cannot see page Y." and proceeds to prevent the UI page Y from rendering if the user doesn't have permission X. They completely ignore securing the back-end API endpoint as that's not a requirement. Now you have a back-end API endpoint that isn't doing any permission checks and anyone can call it even if they don't have permission X.

2. Allowing different values to be used when checking authorization and subsequently persisting data.

A user posts to a URL to add an item to an order.

URL:

  POST /app-web/orders/144/items

PAYLOAD:

  {
    "item_id":682,
    "order_id":555
  }


  @POST("/orders/{orderId}/items")
  public void addItem(@PathParam("orderId") Integer 
  orderId, OrderItem orderItem) {
    checkOwnsOrder(orderId);
    repo.create(orderItem);
  }

The application logic is written to check that the user has access to the order identified in the URL (144). But the payload has a different order id (555). The application allows the item to be added to the order but in this case the order being altered is order number 555 and not the order that the user originally had the ability to add items to, 144.

yeah that's the kind of entry I'm thinking about. I'm hopeful that in the full version they'll explain more detail but it will need that explanation to make it meaningful.