Mówisz, że potrzebujesz rozwiązania „bezserwerowego”. Ale to oznacza, że nie masz możliwości umieszczenia żadnego „swojego” kodu w pętli. (UWAGA: gdy już przekażesz swój kod klientowi, jest to teraz „jego” kod). Blokowanie CORS nie pomoże: ludzie mogą łatwo napisać narzędzie inne niż internetowe (lub serwer proxy sieci Web), które dodaje poprawny nagłówek CORS, aby nadużywać systemu.
Duży problem polega na tym, że nie możesz rozróżnić różnych użytkowników. Nie możesz pozwolić jednemu użytkownikowi na wyświetlanie listy / uzyskiwanie dostępu do jego plików, ale uniemożliwić innym to. Jeśli wykryjesz nadużycie, nie możesz nic zrobić poza zmianą klucza. (Które prawdopodobnie napastnik może po prostu odzyskać).
Najlepszym rozwiązaniem jest utworzenie „użytkownika IAM” z kluczem do klienta javascript. Daj mu uprawnienia do zapisu tylko do jednego zasobnika. (ale najlepiej nie włączaj operacji ListBucket, co uczyni ją bardziej atrakcyjną dla atakujących).
Gdybyś miał serwer (nawet prostą mikro-instancję za 20 $ / miesiąc), mógłbyś podpisać klucze na swoim serwerze, monitorując / zapobiegając nadużyciom w czasie rzeczywistym. Bez serwera najlepsze, co możesz zrobić, to okresowe monitorowanie pod kątem nadużyć po fakcie. Oto, co bym zrobił:
1) okresowo zmieniaj klucze tego użytkownika IAM: co noc generuj nowy klucz dla tego użytkownika IAM i zastępuj najstarszy klucz. Ponieważ są 2 klucze, każdy klucz będzie ważny przez 2 dni.
2) włącz rejestrowanie S3 i pobieraj dzienniki co godzinę. Ustaw alerty dotyczące „zbyt wielu przesłanych plików” i „zbyt wielu pobrań”. Będziesz chciał sprawdzić zarówno całkowity rozmiar pliku, jak i liczbę przesłanych plików. Będziesz chciał monitorować zarówno sumy globalne, jak i sumy na adres IP (z niższym progiem).
Te testy można przeprowadzić „bez serwera”, ponieważ można je uruchomić na komputerze stacjonarnym. (tj. S3 wykonuje całą pracę, te procesy tylko po to, aby ostrzec Cię o nadużyciu wiadra S3, abyś nie otrzymał gigantycznego rachunku AWS pod koniec miesiąca).