From my f0rt1f1ed31337h4ck3r fortress (Ubuntu server) as a tool to assist developers I want to run a server process that will accept HTML files submitted as text and render them server-side for the user, for example to show what it looks like at various screens sizes. I'll track chrome to make sure it doesn't run too long and as the chrome process finishes the screenshot, I'll serve it to the user as an image file from the same box, same web server.

I want to use the following security model:

1. No sandboxing except default headless Chrome's!!, run Chrome directly on written .html files that my server process writes out to disk while saving a screenshot! OMG!!!! The line would be: start chrome --headless --disable-gpu --screenshot=(absolute-path-to-directory)/screenshot.jpg --window-size=1280,1024 file:///(absolute-path-to-directory)/input.html -- why this will work: basically, if an html file would be able to do anything to the local system then it would be an Internet-wide vulnerability so I think this is not allowed.
2. Accept any content up to a certain large length such as 100 megabytes, with 5 workers for small files (under 1 megabyte), 5 workers for medium size files (between 1 megabyte and 5 megabytes), and 1 worker for large files (over 5 megabytes).
3. When received, save them to local files ending in the request number (1.html, 2.html and so forth).
4. Call Chrome headless on the html file and write out screenshot of its output. Monitor this process and give it 10 seconds per user of render time, or when there is a queue up to 300 seconds which is about as long as a user would wait.
5. Throttle concurrent requests to up to a maximum number of concurrent requests per IP, deny additional requests until previous work is finished.
6. Above a certain queue size introduce wait times to slow the number of requests being made (patient users will wait longer) and prioritize small files.

Here is why I think this security model works:

• Content from the web is inherently untrusted (a web site can't give Chrome content that would cause any problems) and in fact Chrome limits javascript functionality even more severely for local files, they have highly limited ability to read any other file.

• Chrome security is extremely airtight, it is the largest and most secure browser, developed by a trillion dollar company (Alphabet/Google).

• The Chrome engine V8 is used for many highly security-conscious applications such as the entire NPM ecosystem as well.

For this reason, I believe it should be safe for me to run chrome directly on html content written by the server for the purposes of producing the screenshots.

However, since this is not the usual use case, I would be interested to know of any failure cases you can think of.

For example, I would like the user to be able to include external files such as externally hosted style sheets, but this inherently makes it possible for the html file to make other external requests.

If there are misconfigured web sites that take actions based on a GET request then my server could be used to make those requests while hiding the IP of the real perpetrator.

For example, suppose there is some website:

website.com

That allows actions via get

https://website.com/external_action/external_action.html?id=4598734&password=somepassword&take_action=now

and just by retrieving this then website.com takes the specified action even though this would be a misconfiguration since it is not the source origin. Thus it may potentially be possible for my web site to allow attackers to take external actions by retrieving a certain file on the misconfigured web server, while hiding their tracks behind my server, even though this is against the guidance set by Internet standards since get requests should be idempotent.

is my concern valid in practice? Are there any other security implications I am not thinking of?

Overall I would just like to use my website to render documents, as a developer tool, and I think this is safe. However, if it is not safe I could put an extra layer of containerization, thus that I mount the files inside the container and have chrome read from within the container and then write to within the container. I could then read the generated image files and in this case if an html file "escapes" from the chrome sandbox it would still be in a sandboxed VM and couldn't do anything.

But I think this is an extra level of resource usage (vm's have pretty high costs) and I don't think it's necessary. Plus, how would I even know if it's escaped? Do I have to spin up a new VM for each and every request or how would I even know? It seems to me that simpler is better and I can just run chrome headless directly on bare metal to produce the screenshots.

What do you think? Am I missing anything?