Self Service Restore Portal Security Header Required

[dkristek]

Team,

We are requesting that the HTTP response header returned from the restore portal site. We are not receiving the proper response for content-security-policy header. We do see that the response has multiple other responses that are received such as strict-transport-security. Please advise on how to add the content-security-policy header.

Thank you,
Daniel Kristek
Zones LLC

[BlakevB]

Hi Daniel,

“The restore Portal is a js client which connects locally to the Rest API.” And “technically, there's no such service as a 'portal'; the portal is just a single-page application in a browser.”
These are direct quotes from the leader of the VB365 development team. This would be why you are not seeing a web server to edit.

The best way to address this would be to put a reverse proxy or load balancer in front of the server. That way nothing external is directly hitting the VB365 server at all.

[jim.lowry]

The VB 365 best practices guide states the same thing @BlakevB covers. See here: https://bp.veeam.com/sp/SaaS/S_Design/s ... rity-zones. Those options make sense because of the fact that our software does not use a web server at all for the VB 365 Self-Service Portal. There is nothing to provide the returned header from the SSP hosted server.

What I can't find is any public documentation that would explain why this is expected behavior and that it can be safely ignored. I think if we had the details included as part of our security standards and best practices, security team reviews and security audits can be easily addressed when the question arises. Is that something that can be added officially into our public documentation?

[Mike Resseler]

@jim.lowry

I would need to discuss this with our security team, but the practices we have are being reviewed by our security teams

[dkristek]

Team,

I am not looking for a workaround at this time. What would help the most is just an acceptance of risk statement. If the self service restore portal is not driven by a web server and is not able to be compromised in such actions as a web server would be. There is no need to add the content security policy to the header in the first place. If I can provide this kind of statement to the internal security team we can resolve this issue. That is best case scenario for me at this point. We can always continue to work towards feature enhancements in the future but the short term goal is to just get it approved to be deployed as designed.