You do not need to read code to ask good questions
Security is presented as a specialist topic and much of it is. But several of the most common serious failures can be surfaced by a non-technical owner asking straightforward questions and listening to how they are answered.
The questions below are the ones we would want asked about our own work.
1. Is every endpoint authenticated?
The commonest serious flaw is an interface that is protected in the user interface and not on the server. If someone can guess a web address and get data without logging in, everything else is irrelevant.
Good answer: “every route requires authentication by default and we deny unless explicitly opened.” Concerning answer: “the pages check whether you are logged in.” Those are different things.
2. Can one customer reach another's data?
Where a system holds data for several customers, ask specifically how a request for record 1234 is checked against the requester's permissions. This class of flaw — changing an identifier in a URL and seeing someone else's information — is common and serious.
Good answer: scoping enforced at the data layer, plus automated tests attempting cross-account access. Concerning answer: an assurance that the interface does not show the link.
3. Where are the secrets?
API keys, database passwords and tokens should live in a secrets manager or environment configuration, never in the code repository. Ask directly whether any credential has ever been committed to the repository, and what was done about it.
Ask also how credentials are rotated and who has access. “Everyone on the team has the production password” is a fragile arrangement, however trustworthy the team.
4. What is in the logs?
Logs routinely capture more than intended: full request bodies including passwords, personal data, card details. They are also frequently sent to third-party services and retained for months.
- Are passwords and tokens excluded from logs?
- Is personal data redacted before logging?
- Where are logs stored, for how long, and who can read them?
- Does any third-party monitoring service receive request contents?
5. How would you know?
The realistic question is not whether something will go wrong but whether you would find out. Ask what alerting exists for unusual patterns: repeated failed logins, a sudden spike in data access, requests from unexpected places.
Also ask who receives those alerts and what they do. An alert sent to an unmonitored inbox is not detection.
Sensible baseline expectations
- HTTPS everywhere, with no plain-text fallback
- Rate limiting on authentication and anything expensive
- Dependency updates on a schedule, with known-vulnerability scanning
- Backups that have been restored at least once as a test
- Access removed promptly when someone leaves
None of this is exotic and all of it is regularly missing. Asking is usually enough to get it addressed.