Secure Coding and Testing¶
Updated: 2026-06-05
Practical security rules for small apps, games, websites, and web services. This is not enterprise compliance; it is the minimum quality bar before work is released.
Operating Rule¶
Every dev project must include basic security thinking in the spec, implementation, and test report.
No client-facing release ships with open critical or high security issues.
Secure Coding Guide¶
| Area | Rule |
|---|---|
| Secrets | Never commit API keys, tokens, passwords, private keys, or .env files. Use environment variables or the host secret store. |
| Input validation | Treat all user input, URL params, uploaded files, Slack text, and webhook payloads as untrusted. Validate type, size, format, and required fields. |
| Auth and access | Protect private pages, admin routes, client data, invoices, and internal docs. Do not rely on hidden UI alone. |
| Data exposure | Return only the fields needed by the UI. Do not leak stack traces, env vars, tokens, internal paths, or other users' data. |
| File access | Keep file reads and writes root-bounded. Reject absolute paths and path traversal such as ../. |
| Dependencies | Use maintained packages, pin dependencies for deployable apps, and remove unused packages. |
| Errors and logs | Log enough to debug, but do not log secrets, credentials, personal data, or full client documents by default. |
| Web safety | Escape rendered user content, use HTTPS in production, and avoid unsafe inline scripts unless the app is static and controlled. |
Required Tests Before Release¶
| Test type | Required check |
|---|---|
| Acceptance | Every acceptance criterion in spec.md has a pass/fail result. |
| Negative input | Invalid, empty, long, malformed, and unexpected inputs fail safely. |
| Access control | Private routes, files, and actions reject unauthorized users. |
| Secrets | Repo and output review finds no committed secrets or visible tokens. |
| Error behavior | User sees safe messages; logs do not expose secrets or sensitive data. |
| Dependency health | Run the available package audit/check command when the stack supports it. |
Defect Severity¶
| Severity | Meaning | Release rule |
|---|---|---|
| Critical | Data leak, remote code execution, exposed secret, auth bypass, payment/invoice corruption | Stop. Fix before any release. |
| High | Private data exposure risk, broken access control, destructive action without confirmation | Fix before client-facing release. |
| Medium | Security hardening gap or likely misuse path with limited impact | Track and fix before broad rollout. |
| Low | Minor polish, logging, documentation, or hardening issue | May ship if owner accepts the risk. |
Tester Output¶
test: must produce:
- Acceptance results
- Security check results
- Defect list with severity
- Release recommendation:
ship,hold, orrevise - Any untested area and why it was not tested