2

In the past, I've been taught that database schema is crucial and should not be exposed in any way so that users cannot inject the system and steal something from it. However, most of the cases I've heard are all about login functions that a hacker tries to act as another user, to get his/her privilege on the system. I'm not sure if the situation still remains the same when backend database changes to NoSQL.

If the schema is still crucial and should keep secret, should we always use different keys between API response and database? For example, product_name and db_prod_name. And should we always make the structure different between API response and NoSQL database? What will happen if we just directly return the JSON record from the NoSQL database to API?

The topic Is it okay to reveal database's table names? should be different to me since my question is about NoSQL database, such as AWS DynamoDB and MongoDB. I suppose the defense strategy may be different due to the characteristics between SQL and NoSQL are different.

user1802604
  • 143
  • 4

1 Answers1

2

First, keeping a schema secret is not a helpful part of any defense posture. For SQL DBs, preventing SQL injection involves a number of techniques- various bits of database configuration, the use of prepared statements, the sanitization of untrusted input- all of which are practiced by open source projects, the SQL schema of which are public. Similarly, though schemaless DBs don't have fixed schemas, related techniques apply when untrusted data is being persisted. In either case, keeping the schema secret is unnecessary if those other techniques are used, and if they are not, secrecy likely won't help.

The reason to maintain separate schema and field names between database and API has to do with change management.

Your application consumes your database. Other applications, not under your control, consume your API.

It is relatively easy to change your schema and conform your application to it. It is difficult, painful and in many cases unacceptable to force breaking changes on consumers of your API.

So, create a API surface that makes sense for your customers, and then keep as an implementation detail your internal schema and database details. In the beginning this seems like wasted effort, but the success path for APIs involves stability for your customers. Invest in it up front.

Jonah Benton
  • 3,359
  • 12
  • 20