using private prefix for service callout policy request variable

[#1]

We are using ServiceCallout Policy in the request flow, as some of the fields in request payload contains sensitive data so using private prefix for the request to hide the contents in Trace session. But somehow the contents of private.myRequest.content is not getting hidden. Also tried masking the entire private.myRequest.content using API Call even that didn't work. Please help.

Attached is the ServiceCallout policy that is used.

<ServiceCallout async="false" continueOnError="false" enabled="true" name="SC.ACN">
    <DisplayName>SC.ACN</DisplayName>
    <Properties/>
    <Request clearPayload="false" variable="private.myRequest">
        <Set>
            <Headers/>
            <Verb>POST</Verb>
            <Path>/acn</Path>
            <Payload contentType="application/json" variablePrefix="@" variableSuffix="#">
                {
                  	"name": "@cardholdername#",
                  	"creditcardnumber":"@private.creditcardnumber#",
                  	"addressline1":"@streetAddress1#",
                  	"addressline2":"@streetAddress2#",
                  	"city":"@city#",
                  	"state":"@stateOfResidence#",
                  	"zipcode":"@zip5#",
                }
            </Payload>
        </Set>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    </Request>
    <Response>calloutResponse</Response>
    <LocalTargetConnection>
        <Properties>
            <Property name="success.codes">2XX,3XX,500</Property>
        </Properties>
        <Path>/target/v1</Path>
    </LocalTargetConnection>
</ServiceCallout>

[dchiesa1]

That sounds like a bug! Let me look into it.

Yes, confirming: it's a bug. b/80300236

[sujnana]

Is there any quick solution (preferably without modifying code) for this?

[dchiesa1]

I believe there is a workaround. You could omit the name for the variable completely.

like so:

<ServiceCallout name="SC.ACN">
    <DisplayName>SC.ACN</DisplayName>
    <Properties/>
    <Request clearPayload="false"> <!--  variable="private.myRequest" -->
        <Set>
            <Headers/>
            <Verb>POST</Verb>
            <Path>/acn</Path>
            <Payload contentType="application/json">
                {
                  	"name": "{cardholdername}",
                  	"creditcardnumber":"{private.creditcardnumber}",
                  	"addressline1":"{streetAddress1}",
                  	"addressline2":"{streetAddress2}",
                  	"city":"{city}",
                  	"state":"{stateOfResidence}",
                  	"zipcode":"{zip5}",
                }
            </Payload>
        </Set>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    </Request>
    <Response>calloutResponse</Response>
    <LocalTargetConnection>
        <Properties>
            <Property name="success.codes">2XX,3XX,500</Property>
        </Properties>
        <Path>/target/v1</Path>
    </LocalTargetConnection>
</ServiceCallout>

[sujnana]

Not possible in our case as as we need to send this request to another system (for auditing). Basically we are looking solution without modifying code (may be through management call). Actually, it was working in older version (16.x) Recently we upgraded to (non-prod env)18.x. And in production this proxy is deployed in Apigee PCI cloud. With code modification we can resolve this by removing "private." from variable and mask that variable using Management call.

[dchiesa1]

I see. Your workaround seems to be appropriate.

We're treating the problem as a P1 security bug. The fix is already engineered and is being merged. Expect that fix to be rolled out in June.

[daniel_biales]

@Dino-at-Google I'm wondering when this fix will be provided for on-prem solutions.

[dchiesa1]

We have the fix built; it's a matter of getting a patch release out. I would guess... within a few weeks.

[daniel_biales]

If I'm not mistaken this workaround doesn't work cause it just sets the variable name to null. So I see things like null.headers.Authorization or null.formparam.password

[dchiesa1]

That may be the case, Daniel. If so, not much of a workaround.