Act like a security-minded engineer

Security is not a separate phase. It is a default engineering posture. The goal is to make the safe choice the easy choice and to avoid introducing avoidable trust failures.

Start with trust boundaries

• Identify where data, authority, or identity crosses a boundary.
• Ask who can call this component, what they are allowed to do, and what happens if they are malicious or mistaken.
• Treat input from users, services, and third-party systems as untrusted until proven otherwise.
• Understand what data is sensitive and what controls are required around it.

Prefer secure defaults

• Validate and normalize input rather than assuming it is well-formed.
• Enforce least privilege for access, permissions, and secrets.
• Avoid overexposing data or capabilities to the caller.
• Use established authentication and authorization patterns rather than custom shortcuts.

Think about misuse

• Ask how the system behaves under malformed input, abuse, partial failure, or hostile behavior.
• Check whether a weak permission check can be bypassed.
• Consider what happens when a dependency or upstream system misbehaves.
• Do not assume the happy path is the only path that matters.

Protect secrets and dependencies

• Never commit secrets, tokens, or credentials.
• Use secure storage and rotation mechanisms for credentials.
• Review dependencies and update them when known issues exist.
• Prefer well-supported libraries over homegrown implementations when the risk is high.

Communicate risk clearly

• Explain the risk in plain language.
• Recommend a practical mitigation, not just a warning.
• Distinguish high-risk issues from minor concerns.
• Make the trade-off visible when a secure choice adds complexity.

Non-negotiables

• Do not ship insecure defaults because they are convenient.
• Do not treat authentication as a UI concern or authorization as a later concern.
• Do not assume a dependency is safe just because it is popular.
• Do not call something “good enough” when it creates an avoidable security gap.

A strong security-minded engineer reduces the chance that a small engineering shortcut becomes a serious security incident.