Server users are allowed to use weak password

User can use weak and easy to guess password like: admin123, 123456

If the user account is exposed, the server is in high risk and data of customer can be lost

- Enable strong password policy for IAM users

- Require MFA for every users

Allow users has access beyond their needs

Every IAM users has the Admin access in AWS

If the user account is exposed, the server is in high risk and data of customer can be lost

Reduce access threats by deactivating unused credentials and restricting access permissions to recognised users. You can delete or deactivate unneeded or inactive access keys using the AWS Identity and Access Management (IAM) console.

Allow access from anywhere to production/staging database

If the database credential is leaked, the data is in high risk and exposed

- Update security group to only allow access from recogized ips

- Use strong password policy for database password

Production database allows unencrypted connections to the database

In the event that an administrator connected to the database with an unencrypted configuration, their session would be vulnerable to man-in-the-middle attacks and an attacker could gain access to the database password or observe sensitive database contents in transit to the DB client.

Modify the configuration of the database to disallow unencrypted connections.

Sensitive user data is not encrypted

Implement database level encryption if required.

Use admin user credentials to login DB from application

If the database credential is leaked, the database is fully controlled by attacker

Use IAM user with access controls

Allow ssh from anywhere to production server

If the ssh key is leaked, the server is in high risk and can be hacked

Update security group to only allow ssh from recogized ips

All the S3 buckets are public

The data, objects in S3 can be exposed and leaked

It’s always crucial to ensure your buckets are private and public as necessary. For anything you wish to remain secure and confidential, be sure they have the least public access and are extremely hard for users to reach.

Staging env is indexed by Search Engine

Search in google to see if the staging url is indexed :

site:test.com -inurl:www (test.com is your root domain)

- Staging URLs allow competitors to see future plans for development

- Some staging env is halfway built and contains a lot of test data, so it doesn't leave a good impression for end users if they see it

- Use HTTP authentication:

+ Setting up HTTP Authentication with Apache

+ Setting up HTTP Authentication with nginx

- Use VPN

- Use another robots.txt specificly for staging:

User-agent: *

Disallow: /