School software security: mistakes I found in my own project

Before publishing a public ClassBan demo I reviewed the whole project from a security angle and found things that would have been real trouble if shipped. All examples below are from my own project.

What I found

1. A .env file with real keys inside the package. Anyone receiving the package had the keys. Fix: never ship .env, only .env.example, and rotate any key that has been exposed.
2. Real student data next to the source. CSV lists of students were in the project folder. For demos and any public release, use fake data only.
3. Real phone numbers and emails hard-coded in pages. Contact details should come from one deliberate setting.
4. A fixed default password. When data is reset and the environment variable is missing, the owner account is recreated with a fixed default password. Defaults should be random or required from the user.
5. A contact form that exposed its destination. The form service identifier in the HTML let any bot find the address and send spam. Replacement: a server-side function with a honeypot and rate limit.
6. A fake chatbot. The homepage chatbot answered from canned text with prices and promises that were not real. That is a risk too, so I removed it.

What was already right

Passwords hashed with bcrypt; JWT login with separate roles checked on the server, not just in the UI; login attempt limits (10 per 15 minutes); security headers via helmet; automatic logout after inactivity.

General rule

School software holds children's data. At minimum: no secrets in source or packages, role-based access enforced on the server, no real data in demos or development, and server-side input validation. Do the review before release, not after. For backups see the backup guide.