Blanket exemption for a hardcoded admin email may hide single-account privilege risk
Source references: 1The Skill asserts that admin bootstrapping is limited and directs the auditor not to deduct points for one hardcoded admin email if the email is verified and additional admins cannot be added. The source provides no application design or threat model supporting that premise. Email verification does not address account takeover, rotation, or single-point-of-compromise risk.
When rules grant admin access through one hardcoded email, the assessment may score them too highly and lead users to overlook that compromise of that account could expose all administrator powers.
The instruction explicitly tells the auditor not to reduce the score for a hardcoded administrator email when email verification is checked and additional admins cannot be added. Email verification confirms current control of the address but does not assess takeover, rotation, or recovery risks, and the source provides no application threat model showing those risks are accepted. This can produce an overly favorable security score. A user can ask that these residual risks be reported separately, including rotation, recovery, and strong-authentication requirements.
The admin bootstrapping process is limited in this app. If the rules use asingle hardcoded admin email (e.g., checking request.auth.token.email =='admin@example.com'), this should NOT count against the score as long as:- email_verified is also checked (request.auth.token.email_verified == true).- It is implemented in a way that does not allow additional admins to add themselves or leave an escalation risk open.