Security response headers are not present in the actual HTTP response for the ACE-generated 404/500 scenarios.

Problem statement with details.

We are currently conducting half-yearly testing for APIs hosted on IBM App Connect Enterprise (ACE), and our security assessment team has identified an issue related to HTTP security response headers.

Current Configuration

We have configured the following security headers at the library level so that they are added to the response for transactions that reach the API/message flow:

• Cache-Control: no-store, no-cache, must-revalidate

• Content-Security-Policy: script-src 'self', object-src 'none', default-src 'self'

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• X-Content-Type-Options: nosniff

• X-Frame-Options: DENY

• X-XSS-Protection: 1; mode=block

This works for requests that successfully reach the API/message flow, including application-generated success and failure responses.

Issue Observed During Penetration Testing

The security team is also testing malformed or invalid requests, for example by passing special/invalid characters in HTTP header names.

In such cases, ACE rejects the request at the HTTP/listener level itself, before the request reaches the API/message flow or the library-level configuration.

ACE returns an HTTP 500 Internal Server Error response in HTML format. Since the request does not reach the API flow, our configured security headers are not added to this response.

Similarly, when the security team sends a request with an invalid/non-existent URI, ACE generates the HTTP 404 response before the request reaches the API/message flow. The required security headers are again missing from this ACE-generated response.

The security assessment team expects the same security headers to be present even for responses generated directly by ACE, including:

1. Successful API responses

2. Application-generated 4xx/5xx responses

3. ACE-generated 404 responses for invalid URIs

4. ACE-generated 500 responses for malformed/invalid HTTP requests

5. Other HTTP errors generated by the ACE HTTP/HTTPS listener before message-flow processing

Configuration Attempts

We attempted to configure the security headers at the ACE node level using the NodeHttpListener / HTTPSConnector properties.

For example:

Node level:

mqsichangeproperties UFSPBRWB01 -b NodeHttpListener -o HTTPSConnector -n ContentSecurityPolicy -v "\"script-src 'self', object-src 'none', default-src 'self'\"" mqsichangeproperties UFSPBRWB01 -b NodeHttpListener -o HTTPSConnector -n XContentTypeOptions -v nosniff mqsichangeproperties UFSPBRWB01 -b NodeHttpListener -o HTTPSConnector -n XSSProtection -v '"1;mode=block"'

We verified the configuration using:

mqsireportproperties UFSPBRWB01 -b NodeHttpListener -o HTTPSConnector -a

We also attempted the equivalent configuration at the Integration Server/Execution Group level:

mqsichangeproperties UFSPBRWB01 -e <EG_NAME> -o HTTPSConnector -n ContentSecurityPolicy -v "\"script-src 'self', object-src 'none', default-src 'self'\"" mqsichangeproperties UFSPBRWB01 -e <EG_NAME> -o HTTPSConnector -n XContentTypeOptions -v nosniff mqsichangeproperties UFSPBRWB01 -e <EG_NAME> -o HTTPSConnector -n XSSProtection -v '"1;mode=block"'

The configured values are visible when we verify the properties using:

mqsireportproperties UFSPBRWB01 -e <EG_NAME> -o HTTPSConnector -a

However, the headers are still not present in the actual HTTP response for the ACE-generated 404/500 scenarios.

Request for IBM Guidance

Could you please confirm the following:

1. Is there a supported ACE configuration that allows HTTP security response headers to be automatically added to all HTTP/HTTPS responses generated by ACE, including listener-level errors?

2. Specifically, can the HTTPSConnector/NodeHttpListener configuration be used to add custom response headers to errors generated before the request reaches the message flow?

3. Is there any configuration, policy, listener property, or other supported mechanism in ACE 13 that can ensure these security headers are added to ACE-generated 404, 400, 500, and other listener-level error responses?

4. If this is not supported at the ACE listener level, what is the IBM-recommended architecture/configuration for ensuring these security headers are present for both:

   • responses generated by the API/message flow, and

   • responses generated by ACE before the request reaches the API/message flow?

5. Is there any limitation or known behavior in ACE regarding custom HTTPSConnector properties such as ContentSecurityPolicy, XContentTypeOptions, and XSSProtection not being applied to listener-generated error responses?

Our primary requirement is to ensure that the security headers are consistently present for every HTTP response, including requests rejected by ACE before reaching the API flow.

Please let us know the supported configuration or recommended solution for ACE 13.

We can provide the ACE version, configuration output, sample curl requests, and complete HTTP response headers for the successful, application-error, 404, and ACE-generated 500 scenarios if required.