API Definition and Cross-Origin Resource Sharing (CORS)
Defining Your API with OpenAPI
An API definition is like a user manual for your web API. It uses a standard format called the OpenAPI specification to list all the available operations, what data they need, and what they will return. In Azure App Service, you can use this specification to automatically create interactive documentation. This helps other developers understand how to use your API correctly without having to dig through your code.
Understanding and Configuring CORS
Cross-Origin Resource Sharing (CORS) is a browser security rule. By default, a web page loaded from one domain cannot make requests to an API on a different domain. This is the same-origin policy. CORS allows you to safely relax this rule for specific, trusted domains. You configure which external websites are allowed to call your API by listing their addresses as allowed origins. You can also control which HTTP methods (like GET or POST) and headers are permitted.
Implementing CORS Securely
You can set up CORS directly in your application code, for example by using the [EnableCors] attribute in an ASP.NET API. You can also manage it through the Azure portal or Azure CLI using commands like az webapp cors add. For security, you should avoid using a wildcard (*) to allow all origins, especially if your API uses credentials. Instead, explicitly list only the domains you trust. Regularly reviewing this list helps prevent unauthorized access while still enabling necessary integrations.
Enforcing HTTPS and Modern TLS
Transport Layer Security (TLS) encrypts the connection between a user's browser and your Azure App Service app, keeping data private. You should configure your app to require HTTPS and redirect any unsecured HTTP traffic. In the TLS/SSL settings, you can enforce the use of modern protocol versions, like TLS 1.2 or higher, and disable older, less secure versions like TLS 1.0 and 1.1. This protects your application from known vulnerabilities.
Managing TLS in an App Service Environment
For an App Service Environment (ASE), which hosts multiple apps, you can manage TLS settings globally. Using an Azure Resource Manager template, you can add a clusterSettings property to disable outdated TLS versions for all apps in that environment at once. You can also configure the order of cipher suites, which are the specific encryption algorithms used during the TLS handshake. Placing stronger, modern ciphers (like those for TLS 1.3) at the top of the list ensures they are preferred for connections.
Validating Your Configuration
After configuring TLS, it is important to validate that your settings are working correctly. You can use online tools like SSL Labs to scan your app's public endpoint. This test will show which TLS protocols and cipher suites your app supports, confirming that only secure connections are allowed. Regularly updating and checking these settings is a key part of maintaining security and compliance for your application.
Secure Service Connections and Network Integration
Authenticating with Managed Identities
When your app needs to connect to other Azure services (like a database or a key vault), using passwords or keys in your code is a security risk. Instead, you should use a Managed Identity. This is an automatically managed identity for your app in Azure Active Directory. Your app uses this identity to request access tokens, which it then presents to other services. This method is more secure because you never have to manage or store secrets, and you control access through role-based access control (RBAC).
Connecting to Private Networks
Virtual Network Integration allows your app to securely communicate with resources inside an Azure virtual network, such as virtual machines or internal databases. This feature provides outbound connectivity from your app to the private network. For inbound private access to your app, you can use a Private Endpoint. This assigns a private IP address from your virtual network to your app, allowing other resources in the network to reach it without any traffic going over the public internet.
Benefits of Private Connectivity
Using these network integration features creates a more secure architecture. Traffic between your app and integrated services stays on the Microsoft Azure backbone network, improving privacy. It also hides backend resources from public exposure, reducing the attack surface. This setup is essential for applications that need to access sensitive data stored in isolated cloud resources or need to connect to on-premises systems through hybrid connections.