Check for API Management CORS policy wildcard

[BernieWhite]

Existing rule

No response

Suggested rule

Using wildcard * with CORS policies is overly permissive and may make an API more vulnerable to certain API security threats.

CORS policies correct configuration for browsers to prevent misuse.

Pillar

Security

Additional context

https://learn.microsoft.com/azure/api-management/cors-policy https://learn.microsoft.com/azure/api-management/mitigate-owasp-api-threats#recommendations-6 https://learn.microsoft.com/azure/api-management/cors-policy

[BenjaminEngeset]

Microsoft.ApiManagement/service/apis/policies would be the only resource where this can be applied, right @BernieWhite? Or can it be applied at a higher level?

Just thinking about the rule design :shipit:

EDIT: Got it now.

[BenjaminEngeset]

@BernieWhite

Been tinkering a bit.

If either rawxml-link or xml-link is supplied as format property value, we cannot expand and have to exempt, both for pre and in-flight? Within rawxml and xml it should be okay.

Target: -Type 'Microsoft.ApiManagement/service', 'Microsoft.ApiManagement/service/policies', 'Microsoft.ApiManagement/service/apis/resolvers/policies', 'Microsoft.ApiManagement/service/products/policies', 'Microsoft.ApiManagement/service/apis/policies', 'Microsoft.ApiManagement/service/apis/operations/policies'

Questioning what kind of functionality we have to go into child resource of child resource?

[BernieWhite]

@BenjaminEngeset Agreed, rawxml and xml is good, we'll ignore links. For pre-flight expansion PSRule will nest sub-resources under Microsoft.ApiManagement/service so your -Type parameter looks good since we need to handle if the child is deployed separately as well.

For in-flight ideally it would be the same pattern so no really change should be required for the rule. Not all these sub-resources are currently exported though, however I am fine for adding export of these sub-resources to be broken into separate issue for tracking.

This issue should just focus on enabling the rule.

[BenjaminEngeset]

@BernieWhite

Great. What do you think would make most sense in terms of pre-condition, run against only resources with the specific cors policies or get all the resources onto the rule anyways?

[BernieWhite]

@BenjaminEngeset Yes, let try to detect if any CORS policy elements are in the policy. If no CORS policy elements are in the policy we should skip with a pre-conditions. This way:

• Good CORS policies will Pass.
• Bad CORS policies will Fail.
• And policies without CORS configuration will be ignored.