S3 buckets without all four Block Public Access settings on
What does ZopNight detect here?
ZopNight flags an S3 bucket when any of its four bucket-level Block Public Access settings (`BlockPublicAcls`, `IgnorePublicAcls`, `BlockPublicPolicy`, `RestrictPublicBuckets`) is off, or when no configuration exists. The finding is a guardrail gap rather than proof of exposure, since ACLs and policy content are not inspected. It carries a $0 saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-086 |
| Category | compliance |
| Severity | critical |
| Metric | none — pure configuration read |
| Threshold | any of 4 settings off |
| Source | ZopNight |
| Permissions used | s3:ListAllMyBuckets · s3:GetBucketPublicAccessBlock · s3:GetAccountPublicAccessBlock |
Where it applies
Why an incomplete guardrail is critical
S3 Block Public Access is the switch that overrides any bucket policy, access point policy or ACL that would make data public. New buckets do not allow public access by default, but, as the Block Public Access guide notes, users can still modify policies and permissions to allow it. With all four settings on, such a change either fails or is ignored. With any of them off, one careless edit can publish the bucket.
The four settings are BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy and
RestrictPublicBuckets. The first two deal with ACLs, the last two with policies.
Checking bucket and account settings
aws s3api get-public-access-block --bucket my-bucket
aws s3control get-public-access-block --account-id 111122223333The first call returns the bucket’s four values, or an error if the bucket has no configuration. The second returns the account-level settings, which also apply.
How ZopNight evaluates a bucket
Discovery reads the bucket’s Block Public Access configuration and records the bucket as open to public access unless all four settings are true. A bucket with no configuration at all is recorded the same way. The rule fires when that record says public access is possible.
What this finding does not prove
The rule does not read bucket ACL grants or the Principal and Effect of the bucket policy, so a
flagged bucket is not necessarily reachable from the internet today. Treat it as hygiene.
It also looks at bucket-level settings only. S3 applies the most restrictive combination of organization, account, access point and bucket settings, so a bucket in an account with all four account-level settings on is protected even if its own settings are off. When the bucket’s status could not be read, no finding is produced.
Risk with no saving
No money is saved. The severity reflects how much damage a public bucket can do, and how cheap the guardrail is compared with the incident it prevents.
Closing the gap
- Confirm nothing legitimately depends on public access. For a static website, serve it through CloudFront with Origin Access Control instead.
- Turn on all four settings for the bucket:
aws s3api put-public-access-block --bucket my-bucket \ --public-access-block-configuration \ BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true- Remove any ACL grants to
AllUsersorAuthenticatedUsers, and any bucket policy statement that allows"Principal": "*"without a restricting condition. - Turn on account-level Block Public Access so new buckets inherit the protection.