Your intuition is correct in the most important way -- this is not, in any meaningful sense, "secure."
But the way it's defeated is not quite what you envision.
When you click a link on a web page, or your browser loads an image embedded in a page, your browser connects to the web server and sends a request. In the request are the HTTP headers, including one called
Referer:. While not always present (for various reasons that may be outside the scope of this answer), the accompanying value is the URL of the page you were looking at -- in the same browser tab -- when the link was clicked or the image was loaded.
Creating such a policy in S3 implements access control by string-matching this value, submitted by the browser, and almost entirely devoid of any value from a security perspectice.
Referer: header -- easily done with test tools like
curl -v http://example-bucket.s3.amazonaws.com/secret-image.jpg -H 'Referer: http://example.com/good-guy.html') or browser plugins. Now the bucket says "oh, you're on the Good Guy page from example.com? Here's that secret image file you asked for."
So with such an obvious limitation, what is this mechanism actually useful for?
Not securing your content.
It is, however, useful to prevent widespread hotlinking to your content, embedding links to your assets in third party sites, which amounts to theft of your bandwidth. I once encountered a scam site where the creator had googled for pages showing pictures of gift cards. He found such images on one of my sites, but he didn't download them... he embedded links to my images into his scammy HTML. A configuration denying on referer significantly reduces such annoyances... but as it is suitable for very little else.
With S3, you can generate signed URLs on the fly (assuming your site is dynamic) and embed them in the html. This is perhaps the most effective solution, since you specify the period of time for which the URL is valid, and these URLs are immune to tampering to the point of computational infeasibility. CloudFront, in conjunction with S3, allows you to create signed cookies that accomplish similar results but without needing to sign each individual link in each page you render, but individual signed URLs for objects with a very short expiration time, using HTTPS and delivered over HTTPS are an effective mechanism of access control, unlike referring page policies.