T09 · Insecure Skill Coding Practices
- Location
guides/03-advanced-usage.md:284- Finding
Hardcoded JWT Signing Key and Default User Credential in Authentication Template
- Content
View full analysis
Vulnerability Details
File Location:
guides/03-advanced-usage.md, lines 284–311
Vulnerability Type: Hardcoded authentication secrets and credentials
Risk Level: HighVulnerable Code
python SECRET_KEY = "09d25e094faa6ca2556c818166b7a9563b93f7099f6f0f4caa6cf63b88e8d3e7" ALGORITHM = "HS256" ACCESS_TOKEN_EXPIRE_MINUTES = 30 password_hash = PasswordHash.recommended() oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token") # Data models class Token(BaseModel): access_token: str token_type: str class TokenData(BaseModel): username: str | None = None class User(BaseModel): username: str email: str | None = None disabled: bool | None = None class UserInDB(User): hashed_password: str # Simulated user database fake_users_db = { "johndoe": { "username": "johndoe", "email": "johndoe@example.com", "hashed_password": password_hash.hash("secret"), "disabled": False, } }A second insecure placeholder is shown in the environment configuration example at
guides/03-advanced-usage.md, line 622:bash SECRET_KEY=super-secret-keyTechnical Analysis
The documented authentication implementation uses a fixed, publicly known symmetric key for HS256 JWT signing and verification. Because HS256 uses the same secret for both operations, possession of this key allows an attacker to generate tokens that pass signature validation.
The template also creates a known default account whose password is derived from the literal value
secret. Although the password is stored as a hash at runtime, the underlying password is disclosed in the documentation and can be used directly against an application that deploys the example unchanged.The Skill presents this as a complete authentication implementation and states that the AI can automatically implement JWT authentication. Consequently, generated applications may inherit these values if developers do not replace them. The environm ...[truncated 1734 chars]
- Remediation
View remediation
Remediation Suggestions
-
Remove all fixed signing keys and default passwords from generated authentication code.
-
Generate a unique, cryptographically secure secret for each deployment, for example with Python's
secrets.token_urlsafe(64). -
Load the signing key from a protected environment variable or dedicated secret manager rather than source code or committed
.envfiles. -
Make the signing key mandatory and fail application startup when it is absent, too short, or equal to a known placeholder.
-
Add validation similar to:
python import os SECRET_KEY = os.environ["SECRET_KEY"] insecure_values = { "super-secret-key", "change-me", "09d25e094faa6ca2556c818166b7a9563b93f7099f6f0f4caa6cf63b88e8d3e7", } if len(SECRET_KEY) < 32 or SECRET_KEY in insecure_values: raise RuntimeError("A strong, deployment-specific SECRET_KEY is required") -
Remove the default
johndoeaccount from production templates. If sample credentials are required for a tutorial, clearly isolate them in test-only code and prevent their use when production mode is enabled. -
Rotate the signing key and invalidate all existing tokens if the documented key has ever been deployed.
-
Keep secret files outside version control, restrict their filesystem permissions, and use deployment-platform secret injection.
-
Consider asymmetric JWT signing where appropriate so verification services receive only a public key, while the private signing key remains isolated.
-
Add automated security tests that reject known placeholder secrets and verify that forged or previously signed tokens fail after key rotation.
-