SELECT * Security

The primary security challenge with both SQL and NoSQL databases is the risk of record-dumping queries, such as a “SELECT *” request.

When combined with SQL injection or GraphQL injection vulnerabilities, attackers can exploit these queries to dump entire database in a matter of seconds.

To address this threat, the original version of Databunker Pro was designed to retrieve user records only when specific user details were provided. This approach significantly limited attackers' ability to enumerate users stored in Databunker. Even if an attacker managed to obtain a Databunker Pro access token, they would still need to provide specific details like the user’s email, phone number, or UUID to access any information. From a security perspective, this design was robust and highly effective.

The Usability Dilemma

Despite the strong security model, we began losing business. Companies provided feedback that they needed a way to list all users as part of their application’s admin interface.

Initially, we firmly opposed introducing any API that allowed bulk user retrieval, as it conflicted with our strict security principles.

However, this resistance came at a cost. While our security model remained robust, our product’s usability suffered, which negatively impacted our business.

We realized we needed a solution that could balance these conflicting requirements: maintaining high security while providing admins with essential functionality.

Iteration 1: Adding Basic Controls for Bulk Access

Our initial attempt to balance usability and security introduced a two-step approach:

1. Configuration Setting: Admins could enable or disable the ability to dump user records entirely.
2. POST Request Requirement: A bulk data dump required a POST request, ensuring the action couldn’t be triggered by a simple GET request.

This solution addressed some concerns but still left room for improvement.

Iteration 2: Secure Unlock Mechanism

Over time, we developed a more secure solution:

1. Unlock Request: A special API unlock request must be submited, specifying whether they want to unlock all users or a specific group of users.
2. Temporary Token: The unlock request generates a temporary token with a short expiration window (e.g., a few minutes).
3. Token Validation: During the token’s validity period, user records can only be dumped if the token is included in the API request.

This approach ensured that bulk data access required explicit admin intent, was time-restricted, and could not be abused by malicious actors.

Conclusion

By evolving our approach from basic controls to a secure unlock mechanism, we successfully balanced security and usability. The unlock-and-token method allowed us to meet customer requirements for admin functionality while maintaining the strong security principles that Databunker Pro is known for.

This iterative process highlights how addressing user feedback and evolving product features can strengthen both usability and trust without compromising security.