In November 2013, Toyota Connected Corporation provisioned a cloud database with no authentication. In April 2023, nine years and five months later, an external researcher found that location data for 2.15 million vehicles was accessible without a credential. No attacker needed to exploit a vulnerability. The endpoint had been open since day one.
Cloud storage misconfigurations are not configuration mistakes. They are access control decisions made by platform defaults, in favor of convenience. AWS S3, Firebase, and Azure Blob Storage each shipped with different defaults, each with a documented exploitation pattern and a published incident to anchor it.
What "Public" Means Depends on the Platform
S3, Firebase, and Azure implement access control models that are incompatible with each other. A developer who knows S3 ACLs is not prepared to write Firebase Security Rules. All three platforms use the word "public" to describe access states with different causes, layers, and remediations.
S3 operates with three independent layers: object-level ACL (legacy), a JSON bucket policy, and Block Public Access as a global override. An object can be public by ACL even when the bucket policy denies general access. The three layers coexist and overlap in ways that few developers fully understand.
Firebase Realtime Database uses a Security Rules file evaluated on every read and write. No rules in test mode means .read: true and .write: true for any anonymous user. There is no default value that protects a database created in test mode until the developer writes and publishes the rules manually.
Azure Blob Storage operates with two independent controls: the AllowBlobPublicAccess setting at the storage account level and the container access tier (private, blob, container). Both need to be configured correctly to prevent exposure. One does not override the other.
S3: The ACL That Outlived Its Usefulness
S3 launched in March 2006 with ACLs as the primary access control mechanism. For twelve years, public-read was the standard way to serve public content. Block Public Access arrived on November 15, 2018 as an opt-in feature, with no automatic migration for existing resources.
Enabling BPA on a bucket does not remove public ACLs granted to individual objects before that change. The default change announced in December 2022, which made BPA active by default on new buckets starting April 2023, had no effect on any existing bucket.
Toyota Connected Corporation provisioned its infrastructure in November 2013. The database held location data for 2.15 million customers of the T-Connect G-Link, G-Link Lite, and G-BOOK services: GPS terminal IDs, VINs, and time-series location data. No authentication was required to access the endpoint.
The exposure was identified in April 2023, nine years and five months after provisioning. Toyota confirmed the root cause as "insufficient data handling rules at initial provisioning." The BPA default change in 2023 had no effect on that data, because the incorrect provisioning occurred in 2013.
Firebase: Security Rules Are Optional Until Scale Proves Otherwise
Firebase Realtime Database initializes in test mode with the rules {".read": true, ".write": true}, which grant anonymous read and write access to any user. Test mode was designed for a 30-day development window. There is no automatic migration to production mode: the developer must write the rules and publish them before going to production.
In 2018, researchers from Appthority and Zimperium identified 2,271 Firebase databases open for public read, exposing more than 100 million records. Vulnerable Android apps had been downloaded more than 620 million times. In each case, test mode was the initial state that was never changed.
In March 2024, researchers Logykk, xyzeva/Eva, and MrBruh scanned more than 5 million domains. They found 916 production sites with no security rules or incorrectly configured rules, exposing 223.2 million records. Of those records, 20.2 million were passwords, 98% stored in plain text. The same pattern from the 2018 research repeated six years later, at greater scale.
The absence of an automatic migration path from test mode to production mode means that every developer who initialized a Firebase database in test mode created an exposure that persists until manual intervention. Firebase does not issue an alert when test mode rules remain active in production.
Azure: Microsoft Called Its Own Vulnerability "By Design"
In May 2021, UpGuard found that Microsoft Power Apps portals had table permissions disabled by default. Dataverse OData feeds were accessible anonymously at predictable URLs, with no authentication required.
The exposed data covered 47 organizations: COVID-19 contact tracing records, vaccination data, Social Security numbers, employee IDs, and payroll data. Organizations affected included American Airlines, Ford, J.B. Hunt, the State of Indiana, the State of Maryland, the City of New York, and Microsoft itself. The total was 38 million records.
On June 29, 2021, Microsoft closed the case describing the behavior as "by design". The company classified the exposure of 38 million records as an intentional design choice, not an error. After pressure from UpGuard's public disclosure, Microsoft changed table permissions to enabled by default in portals created after the fix.
Azure Blob Storage followed a parallel trajectory. Anonymous access on containers was available by default until August 2023, when Microsoft required a two-step process to enable it on new accounts: first at the storage account level, then at the container. Existing accounts and their containers remained unchanged.
The Common Root Cause: The Provisioning Moment Is the Attack Moment
Toyota: provisioned in November 2013, discovered in April 2023. Nine years and five months between the creation of the misconfiguration and remediation. Power Apps: table permissions disabled by default on every portal created; 47 affected portals required manual remediation after disclosure. Firebase 2024: 916 databases in the initial test mode state, unchanged after initialization.
In all three cases, the access control decision that created the vulnerability was made at the moment the resource was created. The developer was focused on shipping the product. The security review came later, if it came at all.
Annual cloud audits and vulnerability scans miss provisioning misconfigurations because the exposure can predate the monitoring baseline by years. Toyota's nine-year gap demonstrates this precisely: any audit tool deployed between 2014 and 2022 would have found the exposed bucket on the first scan.
Changing a platform default does not remediate resources created before that change. BPA as the default for new buckets in April 2023 does not reach Toyota's November 2013 bucket. Disabling anonymous access on new Azure accounts in August 2023 does not close containers created before that. The zero-retroactivity logic holds across S3, Firebase, and Azure.
Detecting Exposed Cloud Storage Before Attackers Do
S3, Firebase, and Azure Blob Storage follow deterministic URL patterns. Any exposed endpoint can be identified through passive DNS enumeration and direct HTTP before a single byte of data is extracted.
For S3, the virtual-hosted pattern is <bucket>.s3.amazonaws.com. The LIST operation returns the object inventory if the bucket is public. The unauthenticated test:
aws s3 ls s3://<bucket-name> --no-sign-request
HTTP 200 confirms public access.
For Firebase, https://<project-id>.firebaseio.com/.json returns the full database contents if .read: true is active. Project IDs are discoverable in mobile app binaries and frontend JavaScript bundles.
For Azure Blob Storage:
https://<account>.blob.core.windows.net/<container>?restype=container&comp=list
Returns an XML listing if the container access tier is blob or container. The URL is constructible from the account name, with no authentication.
intel.mago.team (MAGO team tool) automates this discovery against an organization's full asset inventory, identifying exposed storage endpoints before an attacker's scan reaches them. Unlike SSRF and IMDS attacks that require a prior vulnerability to work, the direct public access demonstrated by the Toyota incident requires no exploitation chain.
The default is the attack surface. The creation date of every bucket, database, or container is the date the exposure began. For the 47 organizations in the Power Apps case, for the 916 Firebase sites in 2024, and for Toyota, the answer came from external sources, never from internal controls.
Top comments (1)
The Toyota example is a great wake-up call — a misconfiguration sitting unnoticed for almost a decade shows how easy it is to "set and forget" cloud storage permissions. Do you have a recommended checklist for auditing S3/Firebase configs regularly, or is this mostly caught by automated scanning tools?