AppSecSchool:
Where should your security controls go?

The Crucial Aspect of Control Placement in Application Security

When it comes to application security, one might often wonder, "Where should I position my controls?". It's a valid question, and its answer plays a significant role in the effectiveness of security measures.

Examples to Consider

Let's examine a few scenarios:

1. Ensuring all email addresses in a system are unique to uphold user data integrity.
2. Preventing Insecure Direct Object References (IDOR), a prevalent threat leading to potential data exposure.

Where should these controls be situated?

The Golden Rule: Proximity

A simple yet effective guideline to remember is: Place your controls as close as possible to what you're safeguarding.

For instance, when ensuring the uniqueness of email addresses during user registration, the most effective place for these controls is directly within the database. Why?

• Duplicating the unicity constraint offered by a database in the code isn't straightforward.
• Embedding this control in the database makes it future-proof. If multiple applications interface with the database over time, the control doesn't need replication.

Avoiding such duplications is essential. Otherwise, one lands in the tedious situation of keeping controls in sync across applications, accumulating unnecessary technical debt.

Similarly, when countering IDOR, the control should be adjacent to the data, typically in the microservice accessing it.

The Pitfalls of Distant Controls

While it might seem enticing to use an API Gateway, it's far from the data and might not be the best solution. Why?

• This method is more of a patch than an actual solution. In AppSec engineering, the goal is to address the core problem, not merely its manifestations.
• Placing controls too upstream overlooks the vast knowledge accumulated from years of web security research. Issues like path manipulation, parsing library disparities, and the potent HTTP Desync Attacks can bypass these controls.
• Such an approach might dent the security culture. The development team could perceive security as someone else's domain, leading to reduced ownership.
• Duplicating routes equates to duplicating logic. Additional tools like WAFs and API gateways, despite their utility, aren't without vulnerabilities.

Yes, there's room for controls that act early, such as when no authentication is evident. And API Gateways can be useful for immediate patching. However, these shouldn't be the foundation of one's security strategy.

In Summary

Whether the task is email validation or preventing IDOR, the principle remains: Keep controls close to the data they protect. This strategy enhances their effectiveness, curtails technical debt, and bolsters a genuine security culture within teams.