Firebase Storage: co to je, nahrávání souborů a ukládání v cloudu

Co je Firebase Storage a jak je strukturován

Firebase Storage je cloudové objektové úložiště postavené na Google Cloud Storage, které poskytuje SDK pro platformy Android, iOS a web. Každý soubor je uložen jako objekt v bucketu Google Cloud a je adresován cestou připomínající souborový systém: gs://bucket-name/path/to/file.jpg. Velikost jednoho souboru může dosáhnout 5 TB, což umožňuje ukládání libovolných multimediálních dat bez předchozí komprese.

Architektura Firebase Storage používá referenční model odkazů (gsutil references) namísto klasické hierarchie složek, i když SDK poskytuje rozhraní s adresáři pro pohodlí vývojáře. Fyzicky jsou všechny objekty uloženy v plochém jmenném prostoru bucketu a virtuální složky jsou vytvářeny pomocí prefixů cest. To zajišťuje lineární výkon vyhledávání bez ohledu na počet souborů.

Hlavní výhoda Firebase Storage oproti přímému použití Google Cloud Storage je vestavěná integrace s Firebase Authentication a Security Rules. Vývojář nemusí nastavovat samostatné role IAM a servisní účty: pravidla přístupu se píší v deklarativním jazyce podobném Firebase Realtime Database Rules a automaticky se aplikují při každém požadavku.

Struktura bucketu a cesty k souborům

Bucket Firebase Storage se vytvoří automaticky při aktivaci služby v konzoli Firebase. Cesta k souboru se vytváří podle principu /název_složky/název_souboru a může obsahovat vnořené úrovně. Doporučuje se organizovat cesty podle schématu /users/{userId}/images/{imageId}.jpg pro izolaci dat mezi uživateli. Taková struktura zjednodušuje psaní bezpečnostních pravidel, protože cesta obsahuje identitu vlastníka.

Je důležité pochopit, že Firebase Storage není relační databáze nebo souborový server v klasickém smyslu. Jedná se o objektové úložiště optimalizované pro operace čtení a zápisu celých souborů. Aktualizace části souboru není možná: při opětovném nahrání se stejnou cestou je starý objekt nahrazen novým. Pro ukládání malých strukturovaných dat použijte Firebase Realtime Database nebo Cloud Firestore.

Ceny a limity Firebase Storage

Ceny Firebase Storage závisí na objemu uložených dat a počtu operací. Bezplatný tarif (Spark) zahrnuje 5 GB úložiště, 20 000 zápisových operací a 50 000 čtecích operací denně. Placený tarif (Blaze) se platí podle skutečného použití: $0,026 za GB uložených dat, $0,05 za 10 000 zápisových operací a $0,004 za 10 000 čtecích operací. Dodatečně se účtuje odchozí provoz.

Pro většinu mobilních aplikací s několika tisíci uživateli je bezplatný limit dostačující ve fázi prototypování a testování. Při škálování na stovky tisíc uživatelů náklady na Storage zřídka přesahují $50–$100 měsíčně při optimalizovaném přístupu k nahrávání a cachování na straně klienta.

Jak nahrávat soubory do Firebase Storage

Nahrání souboru do Firebase Storage se provádí pomocí odpovídající metody SDK, která přijímá cestu v úložišti a data souboru (pole bajtů, URI, stream nebo Bitmap). SDK automaticky spravuje připojení, při velké velikosti rozděluje soubor na části a poskytuje zpětná volání pro sledování průběhu. Nahrávání probíhá přímo z klientského zařízení do Google Cloud, mimo váš server, což snižuje zatížení vaší infrastruktury.

Pro Android používá Firebase Storage SDK třídy StorageReference a UploadTask. StorageReference se vytváří z kořenové cesty pomocí Firebase.storage.reference a ukazuje na konkrétní soubor v bucketu. UploadTask vrací posluchače průběhu, pozastavení a dokončení. Při přerušení připojení UploadTask automaticky pokračuje v nahrávání od posledního úspěšně odeslaného bajtu — toto chování se nazývá obnovitelné nahrávání (resumable upload).

Metadata souboru (Content-Type, vlastní pole) se přenášejí samostatným objektem SettableMetadata při spuštění nahrávání. Správné nastavení Content-Type je kritické pro správné zobrazení souborů v prohlížeči a fungování CDN cachování. Firebase Storage podporuje všechny standardní MIME typy: image/jpeg, image/png, video/mp4, application/pdf a další.

Správa metadat při nahrávání

Metadata souboru obsahují systémová pole (Content-Type, Cache-Control, Content-Disposition) a vlastní páry klíč-hodnota (customMetadata). Systémová pole řídí HTTP hlavičky při stahování. Například Cache-Control: public, max-age=31536000 zapíná cachování odpovědi na jeden rok, což výrazně snižuje počet opakovaných stažení stejného souboru a šetří provoz.

Vlastní metadata jsou vhodná pro přenos dodatečných informací o souboru bez vytváření samostatné kolekce ve Firestore. Například do pole uploadedBy můžete uložit userId uživatele, který soubor nahrál, což zjednodušuje implementaci galerií s autorským obsahem. Vlastní metadata nejsou samostatně chráněna Security Rules — přístup k nim se řídí stejnými pravidly jako k samotnému souboru.

Hromadné nahrávání a dávkové zpracování

Při potřebě nahrát více souborů současně (například fotografie z galerie) se nedoporučuje spouštět nezávislé UploadTask paralelně bez omezení. Na mobilních zařízeních vede paralelní nahrávání více než 3–5 souborů k přetížení síťového zásobníku a časovým limitům. Optimální strategií je použití konkurenčního limitu 3 nebo sekvenční nahrávání s zobrazením společného indikátoru průběhu.

Pro serverové zpracování po nahrání (generování náhledů, komprese, moderace obsahu) použijte trigger Firebase Cloud Functions: functions.storage.object().onFinalize(). Tato funkce se automaticky volá po dokončení nahrání každého souboru a může uložit zpracovanou kopii na jinou cestu. Více o tom v části o typických scénářích.

Stahování souborů a správa odkazů

Firebase Storage podporuje dva způsoby stahování: přímé stažení přes SDK s získáním pole bajtů nebo lokálního souboru a získání přímé download URL pro přístup přes HTTP. Přímou URL lze použít pro zobrazení obrázků v ImageView, v WebView nebo pro poskytnutí odkazu uživateli. Download URL se generuje s bezpečnostním tokenem, který lze odvolat v konzoli Firebase.

Metoda storageReference.downloadUrl vrací URL ve tvaru https://firebasestorage.googleapis.com/v0/b/{bucket}/o/{path}?alt=media&token={token}. Bezpečnostní token se automaticky zahrnuje do URL při generování, takže odkaz lze předat třetím stranám (například v messengeru) bez rizika neoprávněného přístupu. Pokud je však token kompromitován, lze jej odvolat přes konzoli Firebase v sekci Storage — poté všechny odkazy s tímto tokenem přestanou fungovat.

Pro cachování stažených souborů na klientovi použijte lokální úložiště a mechanismus ETag nebo MD5 hash. Firebase Storage vrací HTTP hlavičku ETag při požadavku na soubor, kterou lze porovnat s lokálně uloženou hodnotou a vyhnout se opakovanému stahování nezměněných souborů. To je užitečné zejména pro multimediální obsah: avatary, obálky, náhledy — soubory, které se zřídka aktualizují, ale často vyžadují.

Přímé download URL a jejich bezpečnost

Download URL s tokenem je hlavní způsob poskytování přístupu k souborům pro neautentizované uživatele (například pro zobrazení obrázku v proudu zpráv). Token se generuje jednou a nemění se do odvolání, takže URL lze uložit do databáze (například vedle pole avatarUrl ve Firestore). Při změně avataru se starý soubor smaže a nové URL se vygeneruje a uloží.

Je důležité si pamatovat: existence download URL neruší Security Rules. Pokud pravidlo zakazuje čtení souboru, metoda downloadUrl vrátí chybu Permission Denied. To znamená, že i při znalosti správné cesty k souboru, neautentizovaný klient nezíská odkaz. Po získání URL probíhá přístup k souboru přes HTTP, mimo Security Rules — proto je token jedinou ochranou download odkazu.

Cachování a práce s ETag

HTTP ETag je identifikátor verze souboru, který se mění při každé změně obsahu. Firebase Storage automaticky vrací ETag v odpovědi na GET požadavek. Klientská aplikace může uložit ETag do lokální cache a při opakovaném požadavku odeslat hlavičku If-None-Match: {etag}. Pokud se soubor nezměnil, server vrátí stav 304 Not Modified bez přenosu dat.

Pro implementaci inteligentního cachování v mobilní aplikaci použijte kombinaci lokálního souborového systému a databáze (například Room pro ukládání párů cesta-ETag). Při stahování souboru zkontrolujte ETag z databáze: pokud se shoduje s hodnotou serveru, použijte lokální kopii. Tento přístup snižuje provoz o 60–80% pro statické multimediální soubory a urychluje načítání obrazovek s galeriemi.

Bezpečnostní pravidla pro Firebase Storage

Security Rules je deklarativní jazyk pro omezení přístupu k souborům ve Firebase Storage, který se spouští na straně serveru Firebase. Každé pravidlo je vázáno na cestu v bucketu a určuje podmínky, za kterých je povolena operace čtení (read) nebo zápisu (write). Pravidla se kontrolují před každým požadavkem a nelze je obejít klientským kódem. Toto je jediná linie ochrany dat před neoprávněným přístupem.

Základní pravidlo — přístup pouze autentizovaným uživatelům: allow read, write: if request.auth != null. Takové pravidlo zaručuje, že soubory mohou číst a zapisovat pouze přihlášení uživatelé. Pro jemnější nastavení se používá proměnná request.auth.uid, která obsahuje identifikátor aktuálního uživatele. Porovnáním uid s částí cesty k souboru lze vytvořit izolované úložiště pro každého uživatele.

Důležité: Security Rules nejsou mechanismem pro validaci obsahu. Pokud potřebujete zkontrolovat typ souboru, jeho velikost nebo přítomnost škodlivého kódu, použijte pravidlo request.resource, které obsahuje metadata nahrávaného souboru. K dispozici jsou vlastnosti request.resource.size (velikost souboru), request.resource.contentType (MIME typ) a request.resource.md5Hash (kontrolní součet). Úplná kontrola obsahu se však provádí na straně serveru přes Cloud Functions.

Příklad pravidel pro uživatelský obsah

Typická konfigurace pro aplikaci s uživatelskými avatary a galerií vypadá následovně. Uživatel může zapisovat pouze do svého adresáře /users/{userId}/, ale může číst libovolný soubor v tomto adresáři (galerie je veřejná). Velikost souboru je omezena na 5 MB a typ — pouze obrázky. Taková kombinace pravidel pokrývá 80% scénářů použití Firebase Storage v sociálních a UGC aplikacích.

Bezpečnostní rada: nikdy nepoužívejte pravidlo allow read, write: if true pro celý bucket. To otevírá přístup k zápisu komukoli, kdo zná váš projectId. V roce 2025 došlo k nárůstu útoků na nechráněné Firebase buckety, kdy útočníci využívali otevřený přístup k ukládání nelegálního obsahu. Vždy začínejte s minimálně nezbytnými oprávněními a rozšiřujte je pouze při výslovné potřebě.

Validace obsahu přes Cloud Functions

Cloud Functions trigger functions.storage.object().onFinalize() umožňuje provést kontrolu obsahu po nahrání. Pokud soubor neprojde validací (například obsahuje virus nebo porušuje pravidla platformy), funkce jej může smazat a upozornit uživatele. Toto je jediný způsob kontroly skutečného obsahu, protože Security Rules vidí pouze metadata (velikost a MIME typ), nikoli binární data.

Příklad validace: funkce v Node.js stáhne nahraný soubor do dočasného adresáře, prožene jej antivirovým detektorem (například ClamAV), a pokud je hrozba zjištěna — smaže soubor a zapíše událost do Firebase Crashlytics. Doba provádění funkce je omezena na 540 sekund, což je dostatečné pro kontrolu souborů do velikosti 50 MB.

Příklady kódu pro Firebase Storage v Kotlinu

Podíváme se na praktické příklady integrace Firebase Storage do Android aplikace v Kotlinu. Kód používá standardní třídy Firebase SDK a demonstruje nahrání obrázku z galerie zařízení, stažení souboru se sledováním průběhu a získání download URL. Všechny příklady jsou provedeny s ošetřením chyb a pozastavením úloh při ztrátě připojení.

Před použitím kódu se ujistěte, že v souboru build.gradle je přidána závislost implementation(platform("com.google.firebase:firebase-bom:33.0.0")) a implementation("com.google.firebase:firebase-storage"). Firebase BOM automaticky vybírá kompatibilní verze všech SDK, čímž vylučuje konflikty verzí.

Nahrání obrázku z galerie

První příklad — nahrání souboru, který uživatel vybral přes Intent ACTION_GET_CONTENT. URI získaného souboru se předá Firebase Storage SDK, které samostatně přečte data z tohoto URI. Metoda putFile přijímá URI a vrací UploadTask — objekt, přes který lze sledovat průběh, pozastavovat a obnovovat nahrávání.

val storageRef = Firebase.storage.reference
val imageRef = storageRef.child(
    "users/${auth.uid}/profile.jpg"
)

val metadata = SettableMetadata().apply {
    contentType = "image/jpeg"
    customMetadata = mapOf(
        "uploadedBy" to auth.uid!!
    )
}

imageRef.putFile(imageUri, metadata)
    .addOnSuccessListener {
        Log.d("Storage", "Soubor nahrán")
    }
    .addOnFailureListener { e ->
        Log.e("Storage", "Chyba: ${e.message}")
    }

Ve výše uvedeném příkladu je proměnná storageRef kořenová reference na bucket projektu. Metoda child přijímá řetězec cesty a vrací StorageReference ukazující na konkrétní soubor. Pokud soubor na zadané cestě již existuje, bude přepsán. Metadata contentType a customMetadata se přenášejí přes objekt SettableMetadata, který je připojen k požadavku putFile.

Stažení souboru s průběhem

Druhý příklad demonstruje stažení souboru s získáním pole bajtů pro zobrazení v ImageView. Metoda getBytes() načte celý soubor do paměti. Pro soubory větší než 10 MB použijte getFile() — ukládá obsah přímo do lokálního souboru bez uchovávání v RAM, čímž zabraňuje OutOfMemoryError.

val islandRef = storageRef.child("images/island.jpg")

val ONE_MEGABYTE: Long = 1024 * 1024
islandRef.getBytes(ONE_MEGABYTE)
    .addOnSuccessListener { bytes ->
        imageView.setImageBitmap(
            BitmapFactory.decodeByteArray(
                bytes, 0, bytes.size
            )
        )
    }
    .addOnFailureListener { e ->
        Log.e("Storage", "Nepodařilo se nahrát: ${e.message}")
    }

Pro získání download URL (například pro uložení odkazu do Firestore) se používá metoda downloadUrl:

islandRef.downloadUrl.addOnSuccessListener { uri ->
    Log.d("Storage", "Download URL: $uri")
    // Uložit uri.toString() do Firestore
}

Rada: downloadUrl se generuje jednou a je stabilní, dokud není odvolán. Ukládejte jej do databáze při prvním nahrání, nevyžadujte jej pokaždé při zobrazování souboru. To snižuje počet požadavků na Firebase Storage a urychluje práci UI.

Typické scénáře použití Firebase Storage

Firebase Storage se používá v mobilních aplikacích pro ukládání všech uživatelských a systémových souborů. Nejčastější scénáře jsou avatary a profilové fotografie, obrázky v proudu obsahu, video a audio soubory, dokumenty (PDF, DOCX) pro výměnu mezi uživateli a také zálohování malého objemu dat. Ve všech těchto případech Storage funguje jako specializované úložiště souborů ve spojení s Firestore pro ukládání metadat a odkazů.

Sociální aplikace — nejčastější případ. Každý uživatel nahrává avatar, fotografie příspěvků a mediální soubory. Struktura cest /users/{uid}/posts/{postId}/image.jpg umožňuje izolaci dat a zjednodušuje Security Rules. Při smazání uživatele může Cloud Function projít všechny adresáře uživatele a vyčistit úložiště. Podle Firebase blogu (2025) se tento vzor používá v 70% produkčních projektů na Firebase.

E-commerce aplikace používají Firebase Storage pro ukládání fotografií produktů, katalogů a PDF souborů s instrukcemi. V tomto případě je přístup k souborům obvykle veřejný (čtení bez autentizace) a zápis — pouze pro administrátory přes Cloud Functions s kontrolou oprávnění. Download URL produktů je uložena ve Firestore vedle ostatních dat o produktu, což umožňuje zobrazovat obrázky bez dodatečných požadavků na Storage.

Messengery a chaty ukládají ve Firebase Storage obrázky a hlasové zprávy odeslané v dialozích. Cesta se vytváří jako /chats/{chatId}/messages/{messageId}.jpg. Přístup ke čtení — pouze účastníkům chatu, což se kontroluje přes Security Rules pomocí dat z Firestore. Toto je jeden z mála scénářů, kde pravidlo čte data z jiné služby Firebase: allow read: if firestore.exists(/databases/(default)/documents/chats/{chatId}/members/{request.auth.uid}).