Right now the HTTP API that the job gets its data from and posts its data back through is not authenticated.
This means that if two or more jobs are running at the same time, and one job can correctly guess the request ID of another, it will be able to
Currently guessing is quite easy, as the IDs are based on consecutive numbers.
Mitigation: Use a hard/impossible to guess request ID. Optionally also pass a separate authentication token, which the communication layer enforces.
Workarounds: Either run only one job at a time, or use a N Runner instances with one job each.
Yes, I think giving the browser process a "token" for the job, and then sending it back via Bearer header would help. For even better security, we could JWT-sign the job result. The latter of course implies we provide the client a JWT library.
Right now the HTTP API that the job gets its data from and posts its data back through is not authenticated.
This means that if two or more jobs are running at the same time, and one job can correctly guess the request ID of another, it will be able to Currently guessing is quite easy, as the IDs are based on consecutive numbers.
Mitigation: Use a hard/impossible to guess request ID. Optionally also pass a separate authentication token, which the communication layer enforces.
Workarounds: Either run only one job at a time, or use a N Runner instances with one job each.