For generating PDFs in our web application we have a simple service that accepts a chunk of HTML from the client, wraps it in a standard template, does a couple of simple transforms (like replacing image URLs with inline base64 strings) and renders it as a PDF.

For testing and debugging it is often useful to see what HTML is getting passed to the PDF generator after the wrapping/transform step. However, I'm not entirely convinced that adding this option isn't going to expose some sort of security issue.

If a user is allowed to POST a chunk of arbitrary HTML that gets returned back to them, is there some way that an attacker could take advantage of this?

New contributor
SystemParadox is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 3
    How aware is the user of what it sends, i.e. does she sends data might have been prepared by an attacker? Like blindly uploading some local file one got by mail or maybe upload caused by a CSRF attack? And how is the "returning back" exactly done: as inline (rendered) HTML, as the HTML source (i.e. shown as text), as a downloadable file, ... – Steffen Ullrich 2 days ago
  • If you just want to see the HTML code return it as Content-type text/plain. That should mitigate a lot of risks as long as there are no clients involved that ignore the Content-type. – Robert yesterday
  • The HTML would be returned as text/html so it is rendered on screen. Forcing it to text/plain would make it much less useful. Under normal circumstances the user doesn't have any control over what is sent, they click a button on the screen and it sends the innerHTML of a particular element. But yes there is the CSRF issue. – SystemParadox yesterday

Your Answer

SystemParadox is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.