InlinePolicy expressions with string literals containing quotes are not properly HTML entity escaped

[rggammon]

Description

When using InlinePolicy with C# expressions containing string literals with double quotes, the generated XML does not properly escape the quotes as HTML entities ("). This results in invalid XML that fails Azure API Management policy validation.

Expected Behavior

String literals containing quotes in C# expressions should be automatically escaped as HTML entities in the generated XML output.

Example: StartsWith("/v1/") should become StartsWith("/v1/") in the generated XML.

Actual Behavior

String literals with quotes are left unescaped in the generated XML, causing deployment failures.

Example: StartsWith("/v1/") remains as StartsWith("/v1/") in the XML, breaking XML parsing.

Reproduction Steps

1. Create a policy with InlinePolicy containing a C# expression with quoted string literals
2. Use the Azure API Management Policy Toolkit to generate XML
3. Observe that quotes are not escaped as HTML entities
4. Attempt to deploy to Azure API Management - fails with XML validation errors

Code Example

Policy C# Code

// In a policy class
context.InlinePolicy($"""
    <choose>
        <when condition="@(context.Request.Url.Path.StartsWith("/v1/"))">
            <base />
        </when>
        <otherwise>
            <return-response>
                <set-status code="404" reason="Not Found" />
            </return-response>
        </otherwise>
    </choose>
""");

Generated XML (Incorrect)

<choose>
    <when condition="@(context.Request.Url.Path.StartsWith("/v1/"))">
        <base />
    </when>
    <otherwise>
        <return-response>
            <set-status code="404" reason="Not Found" />
        </return-response>
    </otherwise>
</choose>

Expected XML (Correct)

<choose>
    <when condition="@(context.Request.Url.Path.StartsWith(&quot;/v1/&quot;))">
        <base />
    </when>
    <otherwise>
        <return-response>
            <set-status code="404" reason="Not Found" />
        </return-response>
    </otherwise>
</choose>

Environment

• Azure API Management Policy Toolkit version: 1.0.0
• .NET version: 8.0
• Operating System: Windows
• Build Tool: dotnet CLI

Current Workaround

Using a PowerShell post-processing script to fix escaping after policy generation:

# Fix XML escaping issues in generated policies
$PolicyOutputPath = "deploy/policies"
$files = Get-ChildItem -Path $PolicyOutputPath -Filter "*.xml"

foreach ($file in $files) {
    $content = Get-Content -Path $file.FullName -Raw
    
    # Replace unescaped quotes in expressions with HTML entities
    $fixed = $content -replace '(?<=@\([^)]*)"([^"]*)"(?=[^)]*\))', '&quot;$1&quot;'
    
    if ($content -ne $fixed) {
        Set-Content -Path $file.FullName -Value $fixed -NoNewline
        Write-Host "✓ Fixed XML escaping in $($file.Name)" -ForegroundColor Green
    }
}

Impact

• Deployment Failure: Prevents successful deployment of policies to Azure API Management
• Manual Intervention Required: Requires manual post-processing to fix generated XML
• Developer Experience: Affects any use of InlinePolicy with C# expressions containing string literals
• CI/CD Pipeline Impact: Breaks automated deployment workflows without workaround

Root Cause Analysis

The issue appears to be in the XML generation process, likely in one of these components:

• InlinePolicyCompiler class
• RazorCodeFormatter class
• CustomXmlWriter class

The toolkit correctly handles expression parsing but fails to apply proper HTML entity escaping for quotes within string literals when generating the final XML output.

Suggested Fix

1. Immediate Fix: Modify the XML generation pipeline to automatically escape quotes in C# string literals as HTML entities
2. Long-term Solution: Implement comprehensive HTML entity escaping for all special characters in expressions
3. Testing: Add unit tests to verify proper escaping of various special characters in expressions

Technical Details

• The issue specifically affects InlinePolicy method calls
• Other policy methods using the standard configuration approach do not seem affected
• The problem occurs during the C# to XML compilation phase
• Azure API Management requires valid XML with properly escaped entities

Related Code Locations

Based on repository analysis, the following files may need investigation:

• /src/Core/Compiling/Policy/InlinePolicyCompiler.cs
• /src/Core/Serialization/RazorCodeFormatter.cs
• /src/Core/Serialization/CustomXmlWriter.cs

Additional Context

This issue was discovered during development of Azure API Management policies using the Policy Toolkit v1.0.0. The problem consistently occurs when using string literals containing quotes within C# expressions in InlinePolicy calls.

[rggammon]

I am using github copilot as well (it helped to write this issue) - before InlinePolicy it used c# code but had the same issue with escaping quotes in xml.

    // Global JWT validation for authenticated endpoints only (/v1/ paths)
    if (IsAuthenticatedEndpoint(context.ExpressionContext))
    {
        context.ValidateJwt(new ValidateJwtConfig

...

// Expression method for checking authenticated endpoints
public static bool IsAuthenticatedEndpoint(IExpressionContext context)
    => context.Request.Url.Path.StartsWith("/v1/");

... generates ...

<choose>
  <when condition="@(context.Request.Url.Path.StartsWith("/v1/"))">
    <validate-jwt

... where it needs to be

StartsWith("/v1/"))
```

[FH-Inway]

How are you deploying this to Azure? I recently learned that the xml can be provided in two formats: xml and rawxml. The toolkit creates xml files in the rawxml format. When I use that format when deploying the files, it works.

[Mielek]

Hello @rggammon! Thank you for reporting this issue. I really appreciate that.

As @FH-Inway mentioned, toolkit produced document is a rawxml format. This is closer to .cshtml but I think not fully compatible. You should try to use the rawxml in your azure deployment as it should pass the deployment.

I think this is as well a good place to add a switch in the compiler to allow generating both formats. I think just adding an option to compiler and instead of using my CustomXmlWriter using standard XmlWriter will solve the issue.

Let me know if any one of you would like to implement this option and propagate it. I would love to see new contributors adding code to the project.