You can’t call a system secure unless it’s really secure. Any application that does validation on the client side of the browser can’t afford to bypass it on the server side because someone can always programatically post invalid data. Long back when the app servers and http sessions were just coming up, a few e-commerce applications implemented shopping carts and item pricing using html form hidden variables and got hacked.
Anyway, I am trying to understand the security aspect of using Amazon S3, Amazon’s Simple Storage Service. When a system stores a resource locally, it has the control over serving the resource by authenticating the user. However, when using Amazon S3, this is usually not the case. That is, the very reason most people want to use Amazon S3 is for scalability. This can be achieved only if the url points directly to the Amazon S3 servers itself rather than pointing to your own server. If the url is routed through your own server, then you can do a server-side fetching of the resource stored in Amazon S3 after authenticating the user and then send it. But that defeats the purpose completely since your server becomes a bottleneck. Also, in that case, why store it in S3 and not locally?
Amazon S3 offers query-string authentication mechanism. This passes 3 additional URL parameters, your Amazon Web Services Access Key, Expiration and the Signature which is encrypted string of the resource url and a few other details. This guarantees that a resource is not accessible unless the signature is available, but the moment the url is given to one, and anyone else with an access to the url (which can happen in various ways) can also access the resource. So, essentially there is no user level security. The expiration field (which is also part of the signature, encrypted and safe) offers some level of defense, but still may not be good enough for certain class of secure applications.
So, it’s important to understand the limitations of using an OnDemand Service for powering up your applications. Amazon S3 as a personal backup drive is no brainer. Similarly, using it for completely public access also is no issue. Just those applications that require a tight security based on user (and not just based on the resource itself), can’t make use of S3. This issue is not specific to Amazon S3. Any service, with simple operations as those available in Amazon S3 WebServices will have this issue.
poeticcode 
This is not exactly true. While you can do url based authentication for public files where anyone who has the key can access the file, you can also do token authentication.
The flow is as follow:
Client sends request for file to server.
Server makes a call to S3 to get a new token for that requested file valid for x minutes.
Server redirects client to the S3 url specifying the file and the token.
In this flow client has direct access to the file in S3 for x minutes. After that they need to go to your server again where you can ensure they still have access to see that file.
It does require a little additional server coding but S3 has great API’s that support SOAP and REST with a variety of code samples.
I did mention about the expiration field but that is still not as secure as individual user level authentication. It all depends on what level of security you want.