Redmine

Confirmed the issue.

Setting the target version to 5.1.3.

The root cause of this (along with Safari being weird) is that we are always serving PDF files with content-disposition: inline (#22483), precisely to please the browser's builtin PDF viewers. For PDF files, the download behavior is thus different from all other filetypes.

Initially, Gregor proposed in #22483 to also provide an inline preview of PDF files (similar to images). Unfortunately, Jean-Philippe rejected this inline preview in #22483#note-14 at the time. Personally, I still believe that this would be the more elegant solution as then we could (from the user-perspective) have the consistent interface of an online preview and an actual download button (which would then also send the PDF with content-disposition: attachment). This would allow to avoid weakening the CSP just to please Safari's weird inline PDF viewer. At Planio, we use something quite similar for a long time now.

In any case, please note that removing the sandbox attribute may possible cause an XSS vulnerability if a raw malicious PDF file containing Javascript can be opened in the origin of a Redmine site (which may be possible due to the inline display. The various inline PDF viewers of browsers handle Javascript in PDFs differently internally, but they generally do not execute JS within the download origin (thus avoiding an XSS).

In any case, I do believe that this is an actual browser bug in Safari as it should not apply the PDF file's CSP for its inline reader component. Instead, the reader itself should respect the CSP of the file.

Both Firefox and Chromium / Chrome had similar bugs once which fixed by exempting their respective builtin PDF viewers from CSP restrictions. I believe that Safari should resolve this issue in the same way.