Don't reveal SwaggerHub APIKey in requests from SwaggerHub Integration for Confluence
Could you please consider proxying any authenticated calls from the Confluence page to the SwaggerHub API back through the domain that you presumably serve the widget content from (https://confluence-plugin.swaggerhub.com)? I'm not sure what constraints exist with the Confluence plugin model, but hopefully this would allow you to manage all sensitive state (ApiKey storage) externally in a location we already trust, and form the appropriate authenticated requests to the SwaggerHub API from there. As things stand right now, the SwaggerHub API requests are observable using browser dev tools as the Confluence page renders. These requests include the chosen SwaggerHub ApiKey in the authorization header. This is a security concern for us as we have external parties and partners who we grant visibility to areas of our Confluence tenant so they can view documentation which includes api specifications. Once the ApiKey is compromised, the holder has far more than the readonly-access to specific API specifications that we intended. There are probably other ways to address this, but the proxy approach seemed the most pragmatic to me. We've worked around this issue in the past with other Confluence swagger plugins by only using exported specifications that are attached to the page. However, you are in a good position to allow the convenient referencing of the api specifications in their natural home in SwaggerHub, while keeping the communication paths secure.