| CCC.ObjStor.TH02 | Pre-Signed URLs are Leaked or Over-Scoped | Pre-signed URLs generated with excessive permissions, overly long expiry durations, or insufficient scope constraints may be leaked or shared beyond their intended audience. Because the URL itself acts as a bearer credential, any entity in possession of the URL can access the referenced resource without further authentication, bypassing standard access controls. | 0 | 1 | 1 |
| CCC.ObjStor.TH03 | Objects are Transitioned to a Lower-Durability Storage Class | An authorized entity or misconfigured lifecycle policy may transition objects from a high-durability or high-availability storage class to a lower-durability or single-zone class. This degradation manifests only when a subsequent failure occurs (e.g., availability zone outage). Objects may also be transitioned to archival tiers, rendering them effectively inaccessible for extended retrieval periods during incidents. | 0 | 2 | 1 |
| CCC.ObjStor.TH04 | Objects are Encrypted with Keys Outside Organizational Control | An identity with write access may store or re-encrypt objects using a customer-provided key that the service does not retain, or a key held in a key management service outside the organization's control. The service then holds ciphertext it cannot decrypt on the organization's behalf, so the plaintext is available only to the holder of the foreign key. This results in a loss of availability of the affected data and, where the key holder is external, a loss of confidentiality. | 0 | 2 | 1 |
| CCC.ObjStor.TH05 | Deleted or Overwritten Object Versions Remain Readable | When versioning is enabled, deleting an object records a delete marker and replacing an object creates a new version, while every prior version remains stored. Data that users consider removed is still retrievable by any identity permitted to read object versions, and continues to incur storage cost. This results in a loss of confidentiality for data that was expected to be purged. | 0 | 2 | 1 |
| CCC.ObjStor.TH06 | Object-Level Permissions Diverge from Bucket Policy | When object-level permissions are enabled on a bucket, a permission may be attached to an individual object at upload or afterwards that grants access beyond what the bucket-level policy allows. The object becomes readable or writable by entities the bucket policy does not name, and a review of the bucket policy does not reveal the grant. This results in a loss of confidentiality or integrity of the affected objects. | 0 | 1 | 1 |
| CCC.ObjStor.TH07 | Cross-Origin Requests are Permitted from Untrusted Origins | A bucket's cross-origin resource sharing policy may be configured with a wildcard or overly broad list of allowed origins, methods, or headers. Scripts served from an untrusted web origin can then read or write objects from within an authenticated user's browser session. This results in a loss of confidentiality or integrity of objects in the bucket. | 0 | 2 | 1 |
| CCC.ObjStor.TH08 | Object Immutability is Bypassed or Expires Prematurely | An immutability lock may be applied in a mode that privileged identities can shorten or remove, with a retention period shorter than the record requires, or not applied to objects that require it. Objects intended to be write-once can then be overwritten or deleted. This results in a loss of integrity and availability of records that depend on the lock. | 0 | 2 | 2 |
| CCC.ObjStor.TH09 | Irrevocable Retention Prevents Required Deletion | An irrevocable immutability lock may be applied with an excessive retention period, or to a bucket holding data that is subject to deletion obligations. Neither users nor lifecycle rules can remove the objects until the period expires, and storage cost accrues for the full period. This results in retention of data that should no longer exist, impacting confidentiality and regulatory compliance. | 0 | 2 | 1 |
| CCC.ObjStor.TH10 | Deleted Bucket Names are Reclaimed by Other Tenants | Bucket names are unique across all tenants of the provider (on Azure this applies to the storage account name rather than the container), so when a bucket is deleted its name may be registered by any other tenant. Configuration, code, replication rules, or links that still reference the name then resolve to a bucket under another tenant's control, and data is written to or read from it. This results in a loss of confidentiality, integrity, and availability of the data routed through the reclaimed name. | 0 | 2 | 1 |
| CCC.ObjStor.TH11 | Object Keys and Listing Metadata Expose Sensitive Information | Sensitive values may be placed in object keys, user-defined metadata, or tags. These values are returned by bucket listing operations and recorded in access logs and request URLs, which are governed by weaker access controls than the object content. This results in a loss of confidentiality without any object being read. | 0 | 2 | 1 |
| CCC.ObjStor.TH12 | Untrusted Content is Written to Buckets | Write access may be granted to external systems or through signed URLs without constraints on object content, type, or size. Objects of arbitrary content are stored and later consumed by downstream processes. This results in a loss of integrity for systems that trust the bucket's contents. | 0 | 2 | 1 |