Ideas for Arc XP

Our devs have discovered a security and product issue in Arc XP content API where certain fields containing personal or sensitive information are passed through and can be accessed from the presentation layer, including user emails and internal story comments from Composer. We were even able to see employee IDs of users from other orgs using Arc.

Organizational and systems security are among the highest priorities at our org. Our mission to provide accurate reporting in countries where the press and other forms of free speech are restricted often puts our staff in the crosshairs of authoritarian regimes, online trolls and others who would seek to dissuade our work by any means necessary. Preventing unnecessary exposure of personal information or internal communications is a hard requirement.

As such we are requesting content api product changes that would allow us to exclude such sensitive information. The current workaround to prevent sensitive info being passed in calls involves identifying all fields that shoud be passed using a filter, rather than identifying a known subset that should be excluded. This creates a very significant point of failure as we will constantly be tasked with identifying and adding to the filter everything that should be passed through!

The content-api source holds such a central and fundamental place within Arc XP ecosystem, we have a great deal of concern about diverging from the use of the native source, and instead maintaining our own solution with a rather convoluted filter file. Those specific concerns include:

• Potential complications in accessing new features and system enhancements developed by Arc XP. With each newly released feature we would be required to update our filter file to ensure the necessary fields are not filtered out of the content-api response.

• The likelihood of increased development time on our end. Implementing new features will require meticulous tracking of the filtering on the content-api source to ensure all necessary fields are included.

• The risk of unintended side effects, such as broken blocks, pages, or disruptions to our internal CMS functionality. Given the numerous potential variations in the content-api responses, there is a concern that an accidental omitting of a field in our filter could lead to feature malfunctions.

From our perspective, the ideal solution would involve the ability to pass a list of excluded fields to content-api, much like the available '&includedFields' query parameter.

Of course, it should be capable of handling cases with filtering nested fields, such as content_elements[Nth-element].additional_properties.comments.