I am using a web service (call it X) which allows files to be uploaded to AWS S3.

The way it works is that an initial call is made to X which then returns a list of file descriptors and also meta information which should be injected into the web form as hidden fields that the user is presented with to choose a file to upload. One of these hidden fields is the url of the S3 bucket where the file will be uploaded to.

When the user chooses a file and clicks submit the file is sent as byte streams to the S3 location.

I see two security concerns here:

  1. The url which is returned from calling X and then set as a hidden field in the form could be hijacked and substituted for another url of the hacker's choosing
  2. I am not sure if this is possible but the byte stream from the user's browser to the S3 bucket could be diverted?

Is this paranoia or actual real security concerns?

  • Old question, but: as written, it doesn't make sense. Returning file descriptors to a web browser is meaningless; FDs are just numbers. You say the file is streamed from the browser to S3, but never explain how it gets to the browser (local file picker on the client? Then why send any file-related data to the client?). You talk about changing the URL or redirecting the upload stream, but any attacker that can do that can just copy the file for their own use. You give the client the upload URL, so presumably you don't care what they upload? Most obvious threat seems to be abuse of the URL.
    – CBHacking
    Aug 13, 2021 at 10:31

3 Answers 3


actual real security concerns?

This depends on whether or not the application is properly secured.

  • Is the url served via a secure connection (HTTPS)?
  • Are all common security headers set, especially strict-transport-security?
  • ...and other important headers, like X-Frame-Options to prevent clickjacking?
  • Does the web application have a proper CORS policy/configuration=
  • Is the web page secured against XSS (no vulnerable javascript frameworks used, X-XSS-Protection header properly set)?
  • Is the form submitted via a secure connection (HTTPS)?
  • Is "Service X" trustworthy?

When all of the above is true, and/or set up correctly, I don't see why this shouldn't be less or more secure than having the url already pre-set in the web application.

It would be preferable if service X was under the same control of the owner of the web application itself, since things like "trustworthyness" may change over time.

Just make sure that the application doesn't allow arbitrary upload urls for assets. I've seen that before, that webpage APIs allowed the user to specify the upload-url path, making it possible to create signed upload- and even download-links.

  • Yes all those criteria are met. The only way I can see the url that is returned by service X being hacked is for someone to have temporary access to the person's compute w/o them knowing and modifying the form so that the URL is of the hacker's choosing. Person then comes back and submits the form and the file goes to the hacker's location.
    – Mojo
    Feb 19, 2020 at 12:51
  • @Mojo is the service that sends you back the url not under the control of the same service of the entire web application? Feb 19, 2020 at 13:00
  • No it isn't. It's a bit weird: the situation is as follows: there is a web service A which requires a user to upload a file to AWS S3. In order to do that it needs to call service X which I described in the post to get the information (file descriptors) to upload the file to S3. One of those descriptors is the URL of the S3 bucket. When Service A receives those descriptors, it constructs the web form with those details in hidden fields.
    – Mojo
    Feb 19, 2020 at 14:20
  • Then it depends entirely on how much you can trust 'service X'. Feb 19, 2020 at 15:13
  • Service X is an internal service so I can assume reasonably it is trustworthy. Based on that what is your re-evaluation?
    – Mojo
    Feb 19, 2020 at 15:42

if the security measures were taken in both client side and server side there shouldn't be any problem. all web services should implement these things:

  • the connection should be secure via SSL.
  • if you are posting data to server there should be CSRF tokens in your form fields so untrusted users can't send data to server
  • on the server never trust entered data by users and do data validation

so if you are using third party service just check it's documentation or ask directly from its developers.

please note that setting a filed hidden in the form is not a security measure, it is just for UI so the user don't see unnecessary input field when entering data.


So if I understand you correctly, we have the following scenario: The client makes a call to X, and in return recievs a URL to a S3 bucket. The client then uploads a file to that bucket.

Someone in control of the client (the actual user, or an attacker using a XSS vulnerability or something similar) could upload the file to another S3 bucket, yes. I'm not sure I would consider that a security vulnerability, though. I'm not sure where the file comes from in this scenario, but if it passes the client then the client can do whatever it wants with it. If that is a vulnerability or not depeonds on the situation, I guess.

As for "diverting the byte stream", that is why you should use HTTPS. It protects you against man in the middle attackes.

What makes me curious is how the authentication to the S3 bucket works here. If the client uploads the file, it must be given some sort of credentials from X. What can one do with those, one wounders?

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.