Security best practices in Data API builder

Diagram of the current location ('Optimize') in the sequence of the deployment guide.

Diagram of the sequence of the deployment guide including these locations, in order: Overview, Plan, Prepare, Publish, Monitor, and Optimization. The 'Optimize' location is currently highlighted.

This article includes the current recommended best practices for security in the Data API builder. This article doesn't include an exhaustive list of every security consideration for your Data API builder solution.

Disable Legacy Versions of TLS at the Server Level

Data sent between a client and Data API builder should occur over a secure connection to protect sensitive or valuable information. A secure connection is typically established using Transport Layer Security (TLS) protocols.

As detailed in OWASP's Transport Layer Protection guidance, TLS provides numerous security benefits when implemented correctly:

  • Confidentiality - protection against an attacker from reading the contents of traffic.
  • Integrity - protection against an attacker modifying traffic.
  • Replay prevention - protection against an attacker replaying requests against the server.
  • Authentication - allowing the client to verify that they're connected to the real server (note that the identity of the client isn't verified unless client certificates are used).

Recommendations

One way to help configure TLS securely is to disable usage of legacy versions of TLS at the server level. Data API builder is built on Kestrel, a cross-platform web server for ASP.NET Core and is configured by default to defer to the operating system's TLS version configuration. Microsoft's TLS best practices for .NET guidance describe the motivation behind such behavior:

Note

TLS 1.2 is a standard that provides security improvements over previous versions. TLS 1.2 will eventually be replaced by the newest released standard TLS 1.3 which is faster and has improved security.

To ensure .NET Framework applications remain secure, the TLS version should not be hardcoded. .NET Framework applications should use the TLS version the operating system (OS) supports.

While explicitly defining supported TLS protocol versions for Kestrel is supported, doing so isn't recommended. These definitions translate to an allowlist, which prevents support for future TLS versions as they become available. More information about Kestrel's default TLS protocol version behavior can be found here.

TLS support

TLS 1.2 is enabled by default on the latest versions of .NET and many of the latest operating system versions.