Secure Azure Container Apps: Fix Public Access Risk

Hey guys! Today, we're diving deep into a critical security issue affecting Azure Container Apps, specifically octopetsapi and octopetsfe. It's all about making sure your apps aren't overly exposed to the public internet, which can lead to some serious headaches. Let's break down the problem, understand the risks, and explore some actionable solutions to lock things down.

Understanding the Exposure: Why It Matters

So, what's the big deal? Well, the current setup has these container apps rocking external ingress with no IP security restrictions. This means anyone on the internet can try to access them. To make matters worse, the managed environment has PublicNetworkAccess enabled and sports a public static IP. Think of it like leaving your front door wide open in a not-so-friendly neighborhood. It's just asking for trouble.

The resources in question are:

• /subscriptions/3eaf90b4-f4fa-416e-a0aa-ac2321d9decb/resourceGroups/rg-octopets-test-devday/providers/Microsoft.App/containerApps/octopetsapi
• /subscriptions/3eaf90b4-f4fa-416e-a0aa-ac2321d9decb/resourceGroups/rg-octopets-test-devday/providers/Microsoft.App/containerApps/octopetsfe
• Managed Environment: cae-2tr7b4yvvvogs (staticIp: 130.213.253.254; PublicNetworkAccess: Enabled)

The evidence paints a clear picture: External = true and AllowInsecure = false (which is good, enforcing HTTPS), but IPSecurityRestrictions = [] (which is bad, meaning no restrictions). Plus, there's no CORS policy configured and no client certificate mode set. This combination creates a significant security gap.

Why is this a problem? Unrestricted public access dramatically increases the risk of automated scanning, potential exploitation attempts, and even credential stuffing attacks. Without IP allowlists or a Web Application Firewall (WAF), malicious traffic can directly target your applications. This directly violates several compliance benchmarks, including:

• OWASP Top 10: A01 – Broken Access Control; A07 – Identification and Authentication Failures
• Azure Security Benchmark: NS-1, NS-2 (Network Segmentation and Secure Connectivity); IM-1 (Identity & Access)

In a nutshell, this setup leaves your Azure Container Apps vulnerable to a wide range of attacks. Let's get into how we can fix this.

Impact of Unrestricted Public Access

Having unrestricted public access to your Azure Container Apps is like hosting a party and announcing it on social media with the address but forgetting to hire security or lock your valuables away. The potential impact can be severe, ranging from minor annoyances to full-blown security breaches. Here’s a breakdown of the key risks:

• Increased Attack Surface: With no IP restrictions, your apps are exposed to the entire internet. This dramatically increases the attack surface, making it easier for malicious actors to find and exploit vulnerabilities. Automated scanners constantly probe public IP ranges, looking for weaknesses in exposed services. The more accessible your apps are, the more likely they are to be targeted.
• Brute-Force Attacks: Without rate limiting or other protective measures, attackers can launch brute-force attacks to try and guess passwords or API keys. Publicly exposed login forms and API endpoints are prime targets.
• Reconnaissance and Information Gathering: Attackers can use publicly accessible apps to gather information about your infrastructure, technology stack, and internal processes. This information can then be used to plan more targeted and sophisticated attacks. Even seemingly harmless information can be valuable to an attacker.
• Denial of Service (DoS) Attacks: While Azure has some built-in DDoS protection, unrestricted access can still make your apps more vulnerable to denial-of-service attacks. Attackers can flood your apps with traffic, overwhelming their resources and making them unavailable to legitimate users. This can disrupt your business operations and damage your reputation.
• Data Breaches: If your apps handle sensitive data, unrestricted access can increase the risk of data breaches. Attackers can exploit vulnerabilities to gain unauthorized access to your data, which can have serious legal and financial consequences. Protecting sensitive data is paramount, and restricting access is a key step.
• Compliance Violations: As mentioned earlier, unrestricted public access can violate various compliance regulations and security benchmarks. This can result in fines, penalties, and reputational damage. Meeting compliance requirements is essential for maintaining trust and avoiding legal issues.

In short, unrestricted public access creates a perfect storm of security risks. It's crucial to implement appropriate security measures to mitigate these risks and protect your Azure Container Apps.

Recommended Remediation: Locking Down Your Apps

Alright, let's get down to brass tacks and talk about how to fix this. Here's a step-by-step guide to securing your Azure Container Apps.

1. Restrict Ingress: This is your first line of defense. You need to control who can access your apps.
   • Configure IPSecurityRestrictions: Create an allowlist of trusted IP address ranges. This could include your corporate network's egress IPs, known public IPs of your users, or ranges associated with trusted partners. This ensures that only authorized traffic can reach your apps.
   • Consider Private Ingress: For the highest level of security, switch to private ingress and expose your apps through Azure Front Door Premium with WAF. This hides your apps from the public internet and provides advanced security features.
2. Enforce Edge Protections: If you absolutely need to keep public ingress (and you should really think hard about whether you do), you need to put some serious protection in front of your apps.
   • Azure Front Door or Application Gateway with WAF: This is non-negotiable. A WAF filters malicious traffic, protects against common web exploits, and provides DDoS protection. It's like having a bouncer at your party, keeping the riff-raff out.
   • TLS 1.2+: Make sure you're using the latest TLS protocol for strong encryption. This protects data in transit from eavesdropping.
3. Strengthen TLS and Client Authentication: Go the extra mile to verify your clients.
   • Client Certificate Mode (mTLS): For sensitive endpoints, consider using mTLS. This requires clients to present a valid certificate to access the endpoint, adding an extra layer of authentication. It's like requiring a secret handshake to get into the VIP room.
   • HTTPS-Only: Enforce HTTPS-only access to ensure all traffic is encrypted. Review your custom domains and certificate management to avoid any vulnerabilities. Don't let anyone sneak in through the back door using unencrypted HTTP.
4. Define CORS Policy (for octopetsfe interactions): If your frontend app (octopetsfe) interacts with other services, you need a strong CORS policy.
   • Explicitly Allow Trusted Origins: Only allow requests from trusted origins. Avoid using wildcard *, which allows requests from any origin. This prevents malicious websites from making requests on behalf of your users.
5. Egress and Rate Limiting: Don't just focus on inbound traffic; control outbound traffic as well.
   • Restrict Outbound Access: Use egress controls to limit the destinations your apps can connect to. This prevents compromised apps from communicating with malicious servers.
   • Implement Rate Limiting and Request Validation: Protect your API from abuse by implementing rate limiting and request validation. This prevents attackers from overwhelming your API with requests or injecting malicious data.

Here's an example configuration snippet to get you started:

{
  "configuration": {
    "ingress": {
      "external": true,
      "targetPort": 8080,
      "allowInsecure": false,
      "ipSecurityRestrictions": [
        { "name": "corp-allow", "action": "Allow", "ipAddressRange": "203.0.113.0/24" }
      ],
      "corsPolicy": {
        "allowedOrigins": ["https://app.example.com"],
        "allowedMethods": ["GET","POST"],
        "allowedHeaders": ["*"],
        "exposeHeaders": [],
        "maxAge": 3600,
        "allowCredentials": false
      }
    }
  }
}

Infrastructure as Code (IaC) and API Management (APIM) Considerations

It's crucial to manage your infrastructure as code (IaC) to ensure consistency and repeatability. In this case, the IaC discovery mechanism (GetIaCForGitHub scan) didn't find any IaC files in the BandaruDheeraj/octopets-security repository (branch: main). This means the infrastructure might be managed manually, which can lead to inconsistencies and errors. Consider adopting IaC tools like Terraform or ARM templates to manage your Azure resources.

Also, no Azure API Management (APIM) resources were observed in the resource group. APIM can provide a centralized platform for managing and securing your APIs, including features like authentication, authorization, rate limiting, and analytics. If you're not using APIM, consider implementing it to enhance the security and manageability of your APIs.

Tracking and Next Steps

This issue was identified on 2025-10-22T13:12:20Z in the eastus2 region. The next step is to implement the recommended remediations as soon as possible. Once you've made the changes, share the resource IDs so we can validate them and close this issue.

Remember, security is an ongoing process, not a one-time fix. Stay vigilant, keep your systems up to date, and always be on the lookout for potential vulnerabilities.

This issue was created by security-test--5dec778a and is tracked by the SRE agent here