Systematically audit AWS S3 bucket permissions to identify publicly accessible buckets, overly permissive ACLs, misconfigured bucket policies, and missing encryption settings using AWS CLI, S3audit, and Prowler to enforce least-privilege data access controls.
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionauditing-aws-s3-bucket-permissionsExecute the skills CLI command in your project's root directory to begin installation:
Fetches auditing-aws-s3-bucket-permissions from mukul975/Anthropic-Cybersecurity-Skills and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate auditing-aws-s3-bucket-permissions. Access via /auditing-aws-s3-bucket-permissions in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
0
total installs
0
this week
8.6K
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
8.6K
stars
| name | auditing-aws-s3-bucket-permissions |
| description | 'Systematically audit AWS S3 bucket permissions to identify publicly accessible buckets, overly permissive ACLs, misconfigured bucket policies, and missing encryption settings using AWS CLI, S3audit, and Prowler to enforce least-privilege data access controls. ' |
| domain | cybersecurity |
| subdomain | cloud-security |
| tags | - cloud-security - aws - s3 - bucket-permissions - data-protection - access-control |
| version | '1.0' |
| author | mahipal |
| license | Apache-2.0 |
| nist_csf | - PR.IR-01 - ID.AM-08 - GV.SC-06 - DE.CM-01 |
Do not use for auditing non-AWS object storage (use provider-specific tools), for real-time monitoring (use S3 Event Notifications with Lambda), or for auditing S3 access patterns (use S3 Access Analyzer or CloudTrail S3 data events).
s3:GetBucketPolicy, s3:GetBucketAcl, s3:GetBucketPublicAccessBlock, s3:GetEncryptionConfiguration, and s3:ListAllMyBuckets permissionspip install prowler) for automated CIS benchmark checksCheck the account-level S3 Block Public Access settings first, then list all buckets with their regions.
# Check account-level S3 Block Public Access settings
aws s3control get-public-access-block \
--account-id $(aws sts get-caller-identity --query Account --output text) \
--output json
# List all buckets with creation dates
aws s3api list-buckets \
--query 'Buckets[*].[Name,CreationDate]' \
--output table
# Get bucket regions for each bucket
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
region=$(aws s3api get-bucket-location --bucket "$bucket" --query 'LocationConstraint' --output text)
echo "$bucket -> ${region:-us-east-1}"
done
Iterate through all buckets to evaluate their individual public access blocks and ACL grants.
# Check per-bucket Block Public Access settings
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
echo "=== $bucket ==="
aws s3api get-public-access-block --bucket "$bucket" 2>/dev/null || echo " No Block Public Access configured"
# Check ACL for public grants
aws s3api get-bucket-acl --bucket "$bucket" \
--query 'Grants[?Grantee.URI==`http://acs.amazonaws.com/groups/global/AllUsers` || Grantee.URI==`http://acs.amazonaws.com/groups/global/AuthenticatedUsers`]' \
--output json
done
Review bucket policies for wildcard principals, missing conditions, and statements that allow broad access.
# Extract and analyze bucket policies
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
policy=$(aws s3api get-bucket-policy --bucket "$bucket" --output text 2>/dev/null)
if [ -n "$policy" ]; then
echo "=== $bucket policy ==="
echo "$policy" | python3 -c "
import json, sys
policy = json.load(sys.stdin)
for stmt in policy.get('Statement', []):
principal = stmt.get('Principal', {})
effect = stmt.get('Effect', '')
if principal == '*' or principal == {'AWS': '*'}:
print(f' WARNING: {effect} with wildcard principal')
print(f' Actions: {stmt.get(\"Action\", \"\")}')
print(f' Condition: {stmt.get(\"Condition\", \"NONE\")}')
"
fi
done
Check that all buckets have server-side encryption enabled and versioning configured for data protection.
# Check encryption and versioning status for all buckets
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
echo "=== $bucket ==="
# Encryption configuration
aws s3api get-bucket-encryption --bucket "$bucket" 2>/dev/null \
&& echo " Encryption: ENABLED" \
|| echo " Encryption: DISABLED"
# Versioning status
aws s3api get-bucket-versioning --bucket "$bucket" \
--query 'Status' --output text
# Logging status
aws s3api get-bucket-logging --bucket "$bucket" \
--query 'LoggingEnabled' --output text 2>/dev/null
done
Execute Prowler's S3-focused checks aligned with CIS AWS Foundations Benchmark.
# Run Prowler S3-specific checks
prowler aws \
--checks s3_bucket_public_access \
s3_bucket_default_encryption \
s3_bucket_policy_public_write_access \
s3_bucket_server_access_logging_enabled \
s3_bucket_versioning_enabled \
s3_bucket_acl_prohibited \
-M json-ocsf \
-o ./prowler-s3-audit/
# View summary
prowler aws --checks s3 -M csv -o ./prowler-s3-audit/
Leverage IAM Access Analyzer to identify buckets shared externally or publicly.
# List Access Analyzer findings for S3
aws accessanalyzer list-findings \
--analyzer-arn $(aws accessanalyzer list-analyzers --query 'analyzers[0].arn' --output text) \
--filter '{"resourceType": {"eq": ["AWS::S3::Bucket"]}}' \
--query 'findings[*].[resource,status,condition,principal]' \
--output table
# Create an analyzer if one does not exist
aws accessanalyzer create-analyzer \
--analyzer-name s3-access-audit \
--type ACCOUNT
Compile findings into an actionable report and apply remediation for critical issues.
# Quick remediation: Enable Block Public Access on a bucket
aws s3api put-public-access-block \
--bucket TARGET_BUCKET \
--public-access-block-configuration \
'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'
# Enable default encryption with SSE-S3
aws s3api put-bucket-encryption \
--bucket TARGET_BUCKET \
--server-side-encryption-configuration \
'{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/aws/s3"},"BucketKeyEnabled":true}]}'
# Enable versioning
aws s3api put-bucket-versioning \
--bucket TARGET_BUCKET \
--versioning-configuration Status=Enabled
| Term | Definition |
|---|---|
| S3 Block Public Access | Account-level and bucket-level settings that override ACLs and policies to prevent public access regardless of individual resource configurations |
| Bucket Policy | JSON-based resource policy attached to a bucket that defines who can access the bucket and what actions they can perform |
| ACL (Access Control List) | Legacy S3 access control mechanism granting permissions to AWS accounts or predefined groups like AllUsers or AuthenticatedUsers |
| IAM Access Analyzer | AWS service that analyzes resource policies to identify resources shared with external entities or the public |
| Server-Side Encryption | Encryption applied by S3 at the object level using SSE-S3, SSE-KMS, or SSE-C before writing data to disk |
| CIS AWS Foundations Benchmark | Security best practice standard from Center for Internet Security with specific controls for S3 bucket configuration |
Context: A security engineer receives a Trusted Advisor alert about a publicly accessible S3 bucket. The bucket was created by a development team for a demo and was never locked down.
Approach:
aws s3api get-bucket-acl and find a grant to AllUsers with READ permissionget-bucket-policy and discover a policy with Principal: "*" and s3:GetObjectPitfalls: Enabling Block Public Access can break applications that intentionally serve content publicly (static websites). Always verify the bucket's intended use before applying restrictions. Check for CloudFront distributions or other services relying on the bucket's public access.
S3 Bucket Permissions Audit Report
=====================================
Account: 123456789012 (Production)
Date: 2026-02-23
Auditor: Security Engineering Team
Total Buckets: 47
ACCOUNT-LEVEL SETTINGS:
Block Public Access: ENABLED (all four settings)
CRITICAL FINDINGS:
[S3-001] Public Read Access via ACL
Bucket: marketing-assets-prod
Issue: AllUsers group granted READ permission via ACL
Risk: Any internet user can list and download bucket contents
Data Sensitivity: Contains customer-facing but non-sensitive marketing assets
Remediation: Remove AllUsers ACL grant, enable Block Public Access
[S3-002] Wildcard Principal in Bucket Policy
Bucket: data-exchange-partner
Issue: Policy allows s3:GetObject with Principal "*" and no VPC/IP condition
Risk: Intended for partner access but accessible to anyone with the bucket name
Remediation: Add aws:SourceVpce or aws:SourceIp condition to restrict access
SUMMARY:
Buckets with public access: 3 / 47
Buckets without encryption: 5 / 47
Buckets without versioning: 12 / 47
Buckets without access logging: 18 / 47
Buckets with overly broad policies: 7 / 47
Prerequisites
Time Estimate
15-45 minutes depending on use case complexity
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
I recommend auditing-aws-s3-bucket-permissions for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
auditing-aws-s3-bucket-permissions reduced setup friction for our internal harness; good balance of opinion and flexibility.
Useful defaults in auditing-aws-s3-bucket-permissions — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
auditing-aws-s3-bucket-permissions has been reliable in day-to-day use. Documentation quality is above average for community skills.
Keeps context tight: auditing-aws-s3-bucket-permissions is the kind of skill you can hand to a new teammate without a long onboarding doc.
auditing-aws-s3-bucket-permissions fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
auditing-aws-s3-bucket-permissions reduced setup friction for our internal harness; good balance of opinion and flexibility.
Keeps context tight: auditing-aws-s3-bucket-permissions is the kind of skill you can hand to a new teammate without a long onboarding doc.
I recommend auditing-aws-s3-bucket-permissions for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
Registry listing for auditing-aws-s3-bucket-permissions matched our evaluation — installs cleanly and behaves as described in the markdown.
showing 1-10 of 62