ASVS V6.3.2 requires that default user accounts, for example root, admin or sa, are not present in the application or are disabled. It is a Level 1 requirement.
Default accounts are a gift to attackers because the name is known, the password is often known and the privileges are high. This requirement takes that gift away.
Why it matters
Default names and passwords are the first thing scanners try. A vendor default left on a database or admin panel has caused countless breaches.
Public scanners test common administrator names and vendor default passwords on every address they can reach. Many serious incidents began with a forgotten maintenance login on a database, a router, a management console or a demo tenant. A default account is also hard to audit because no person is responsible for it, so its activity blends into normal noise.
How to implement it
Do not seed a known account in migrations. Create the first administrator through a one time setup flow with a unique name and a strong secret that the operator chooses.
-- check for default accounts in your own schema
SELECT username, is_active FROM users
WHERE lower(username) IN ('admin','administrator','root','sa','test','guest','demo');
Also check third party components: database superusers, message broker consoles, CI runners and bundled admin UIs. Disable or rename them and restrict network access.
Make sure no default credentials sit in the repository either. A secrets scan finds them quickly.
Work through the layers one by one.
- Application: no seeded
adminrow in migrations or fixtures. The first administrator is created in a protected setup step, with a name chosen by the operator. - Data stores: disable or rename built in superusers, require strong generated secrets, and restrict network access to the application only.
- Infrastructure: remove default credentials from message brokers, caches, monitoring dashboards, CI runners and container registries.
- Images and templates: scan base images and infrastructure as code for baked in passwords.
- Code: search the repository history for words like password, default and admin next to a literal value.
Automate the checks so regressions are caught. A pull request gate that fails when a seed file defines a well known username keeps the problem from returning.
# simple CI check for seeded default users
if grep -RniE "(username|user)\s*[:=]\s*[\"']?(admin|root|sa|test)[\"']?" db/seeds migrations; then
echo "default account seeded"; exit 1
fi
How to test it
Run the query above in each environment, then try the common default pairs on every login surface, including staging. Every attempt must fail.
Query each environment for common names and confirm the accounts are absent or disabled. Then try them with an automated login test against every administrative surface: the application, the database port, the broker console, the CI dashboard and the cloud console. Include non production environments that hold real data or reach production networks.
Finally, check the audit log for logins by any generic account name in the last 90 days. Any activity means there is an account you did not know about.
Common mistakes
-
Disabling the account in production but not in staging copies.
-
Leaving seed data with a known password in a Docker image.
-
Renaming admin but keeping the default password.
-
Disabling the account but leaving its API key or token active.
-
Creating a shared break glass account without a unique secret and logging.
-
Assuming that a vendor appliance ships without defaults. Read its hardening guide.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is renaming the account enough?
Only if the password is also unique and strong. The point is that nothing predictable is left.
