AWS Security Best Practices for Web Applications in 2026

AWS Security Best Practices for Web Applications in 2026

AWS security best practices are essential reading for any team running a website or web application on Amazon Web Services. AWS provides powerful security tools, but the shared responsibility model means the security of your application, data, and configuration is entirely your own responsibility. AWS secures the infrastructure; you secure everything running on it.

This guide covers the four highest-impact areas: S3 bucket policies, CloudFront SSL configuration, AWS WAF rules, and IAM least privilege. Each section includes actionable configuration examples.

Scan your public endpoint with ZeriFlow to see how your current AWS setup performs against 80+ security checks — before and after applying these recommendations.

S3 Bucket Policies: Blocking Public Access the Right Way

S3 misconfiguration is one of the most common causes of data breaches in cloud environments. AWS now provides multiple layers of public access controls, and understanding the difference between them is critical.

Block Public Access settings (account level): 1. Go to S3 → Block Public Access settings for this account. 2. Enable all four settings: - Block public access to buckets and objects granted through new ACLs - Block public access to buckets and objects granted through any ACLs - Block public access to buckets and objects granted through new public bucket or access point policies - Block and restrict public access to buckets and objects through any public bucket or access point policies 3. This is a safety net — even if a developer accidentally adds a public bucket policy, it will be blocked.

For static website hosting through CloudFront (recommended pattern): Instead of making your S3 bucket publicly accessible, use Origin Access Control (OAC) to allow only CloudFront to read from your bucket:

{
    'Version': '2012-10-17',
    'Statement': [
        {
            'Sid': 'AllowCloudFrontServicePrincipalReadOnly',
            'Effect': 'Allow',
            'Principal': {
                'Service': 'cloudfront.amazonaws.com'
            },
            'Action': 's3:GetObject',
            'Resource': 'arn:aws:s3:::your-bucket-name/*',
            'Condition': {
                'StringEquals': {
                    'AWS:SourceArn': 'arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID'
                }
            }
        }
    ]
}

This pattern means your S3 bucket has zero public access — only your specific CloudFront distribution can retrieve objects.

S3 encryption:

{
    'Version': '2012-10-17',
    'Statement': [
        {
            'Sid': 'DenyUnencryptedObjectUploads',
            'Effect': 'Deny',
            'Principal': '*',
            'Action': 's3:PutObject',
            'Resource': 'arn:aws:s3:::your-bucket-name/*',
            'Condition': {
                'StringNotEquals': {
                    's3:x-amz-server-side-encryption': 'aws:kms'
                }
            }
        }
    ]
}

Enable S3 Object Lock for compliance buckets where data must not be modified or deleted for a defined retention period.

CloudFront SSL: Enforcing Secure Connections End-to-End

CloudFront sits in front of your origin and can enforce HTTPS at the edge, but only if configured correctly.

Viewer Protocol Policy: In your CloudFront distribution settings under each behavior: - Set Viewer Protocol Policy to Redirect HTTP to HTTPS. - Never choose 'HTTP and HTTPS' — this allows plaintext connections.

Minimum TLS version: - Go to your distribution's Security policy setting. - Select TLSv1.2_2021 or TLSv1.2_2019 at minimum. Never use TLSv1 or TLSv1.1. - For maximum security, use TLSv1.2_2021 which only supports TLS 1.2 and 1.3 with strong ciphers.

Custom SSL certificate: 1. Request a certificate in ACM (AWS Certificate Manager) in us-east-1 (CloudFront requires certificates in us-east-1 regardless of your origin region). 2. Validate via DNS or email. 3. Attach the certificate to your CloudFront distribution under Custom SSL Certificate.

Security headers via CloudFront Response Headers Policy: 1. Go to CloudFront → Policies → Response headers. 2. Create a policy adding: - Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - X-Content-Type-Options: nosniff - X-Frame-Options: DENY - Referrer-Policy: strict-origin-when-cross-origin - Content-Security-Policy: (your policy) 3. Attach this policy to each CloudFront behavior that serves your web application.

AWS WAF: Protection Beyond the Edge

AWS WAF lets you inspect HTTP/HTTPS requests at the CloudFront layer (or ALB/API Gateway) before they reach your origin.

Setting up AWS WAF with CloudFront: 1. Navigate to AWS WAF & Shield → Web ACLs. 2. Create a Web ACL in CloudFront (Global) — this is a separate region for CloudFront-attached ACLs. 3. Add the following managed rule groups (AWS Managed Rules, all free): - AWSManagedRulesCommonRuleSet: General protection against OWASP Top 10. - AWSManagedRulesKnownBadInputsRuleSet: Blocks known attack payloads. - AWSManagedRulesSQLiRuleSet: SQL injection protection. - AWSManagedRulesLinuxRuleSet: Linux-specific attack patterns (relevant if your backend is Linux).

Rate-based rules: Add a rate-based rule to throttle requests per IP: - Rule type: Rate-based rule - Rate limit: 2000 requests per 5 minutes (adjust based on your traffic patterns) - Action: Block

IP reputation list: AWS Managed Rules includes an AWSManagedRulesAmazonIpReputationList that blocks IPs associated with bots and botnets. Enable this as the first rule in your Web ACL for an immediate baseline of bot protection.

Associate the Web ACL with your CloudFront distribution: In the Web ACL settings, under Associated AWS Resources, add your CloudFront distribution.

IAM Least Privilege: The Most Important Security Practice

IAM misconfigurations are a primary cause of AWS security incidents. The principle of least privilege means every user, role, and service gets only the permissions it needs — nothing more.

Avoid IAM users for applications: Do not use IAM users with long-term access keys for your application. Use IAM roles with temporary credentials instead: - EC2 instances: Attach an IAM instance profile. - Lambda functions: Attach an execution role. - ECS/EKS: Use task roles or IRSA (IAM Roles for Service Accounts).

Example: Read-only S3 role for a Lambda function:

{
    'Version': '2012-10-17',
    'Statement': [
        {
            'Effect': 'Allow',
            'Action': [
                's3:GetObject',
                's3:ListBucket'
            ],
            'Resource': [
                'arn:aws:s3:::specific-bucket-name',
                'arn:aws:s3:::specific-bucket-name/*'
            ]
        }
    ]
}

Notice the policy specifies an exact bucket name rather than *. This is least privilege in practice.

Enable MFA for all IAM users:

{
    'Version': '2012-10-17',
    'Statement': [
        {
            'Sid': 'DenyAllExceptMFASetup',
            'Effect': 'Deny',
            'NotAction': [
                'iam:CreateVirtualMFADevice',
                'iam:EnableMFADevice',
                'iam:GetUser',
                'sts:GetSessionToken'
            ],
            'Resource': '*',
            'Condition': {
                'BoolIfExists': {
                    'aws:MultiFactorAuthPresent': 'false'
                }
            }
        }
    ]
}

Attach this policy to all IAM groups to require MFA before any actions can be taken.

Enable AWS Security Hub: Security Hub aggregates findings from GuardDuty, Config, Inspector, and other services into a single dashboard with a compliance score against standards like CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices.

Verifying Your Public Endpoint With ZeriFlow

AWS provides many layers of protection, but what matters to your users and to attackers is what your public endpoint actually returns. AWS-level configurations can be correct while your application still serves missing security headers or weak TLS.

Run a ZeriFlow scan on your CloudFront domain or custom domain to verify: - HTTPS enforcement and redirect behavior - Security headers from your CloudFront Response Headers Policy - TLS version and cipher strength - Certificate chain validity and expiration - HSTS configuration

FAQ

### Q: Should I enable AWS Shield Advanced? A: AWS Shield Standard (free) protects against common network and transport layer DDoS attacks. Shield Advanced adds protection for application layer attacks, near real-time visibility, cost protection for DDoS-related scaling charges, and access to the AWS DDoS Response Team. It costs $3,000/month — it is appropriate for large-scale applications with significant DDoS risk.

### Q: Can I use S3 static website hosting without CloudFront? A: You can, but it is not recommended for production. S3 static website endpoints do not support HTTPS with custom domains, only HTTP. CloudFront in front of S3 gives you HTTPS, a global CDN, WAF integration, and security headers — for most workloads, the overhead of adding CloudFront is negligible.

### Q: How do I audit my existing IAM permissions? A: Use IAM Access Analyzer to identify resources shared externally, and the IAM Policy Simulator to test what permissions a role or user actually has. AWS also offers the Credential Report (IAM → Credential Report) which lists all IAM users and the status of their passwords, access keys, and MFA devices.

### Q: What is the difference between a Security Group and a Network ACL? A: Security Groups are stateful firewalls that operate at the instance level — return traffic is automatically allowed. Network ACLs are stateless firewalls at the subnet level — you must explicitly allow both inbound and outbound traffic. Use Security Groups as your primary control layer and Network ACLs as a secondary backstop.

Conclusion

AWS security best practices for web applications require attention across multiple services and configuration surfaces. S3 bucket policies prevent data exposure, CloudFront SSL enforces encryption at the edge, AWS WAF blocks known attack patterns before they reach your origin, and IAM least privilege limits the blast radius of any compromise.

No single service or setting provides complete protection. Defense in depth — multiple overlapping controls — is the only approach that works consistently in production environments.

Scan your AWS-hosted website with ZeriFlow to get an objective, outside-in view of your security posture. The free scan checks what your endpoint actually exposes to the internet, which is the ground truth that matters most.