Software Development Security · Topic 4 of 4
Secure Coding Guidelines and Standards
Common source-code weaknesses and fixes, OWASP and CERT resources, API security, secure coding practices, failure handling and software-defined security.
- 3 min
- Know the standard fix for each common weakness.
- Validate input, encode output, parameterize queries, fail securely.
- OWASP Top 10 for awareness, ASVS for requirements, CERT for language rules, CWE for weakness types.
What it is
Secure coding guidelines and standards tell developers how to avoid common weaknesses. The security manager's job is to choose the standards, make them practical, and enforce them through training, review and automated checks in the pipeline.
How it works
Common weaknesses and the fixes standards require
| Weakness | Fix |
|---|---|
| SQL injection | Parameterized queries (prepared statements) |
| Cross-site scripting (XSS) | Context-sensitive output encoding, input validation, content security policy |
| Cross-site request forgery (CSRF) | Anti-forgery tokens (per session or per request) validated on the server, same-site cookies |
| Buffer overflow | Bounds checking, memory-safe languages |
| Integer overflow | Validate arithmetic ranges before allocation |
| Path traversal | Canonicalize the path, then validate against an allow list |
| Insecure deserialization | Accept data-only formats, verify integrity before parsing objects |
| XML external entity (XXE) | Disable external entity resolution in the parser |
| Clickjacking | Frame-ancestors restriction or equivalent response headers |
| Session fixation | Issue a new session identifier on login |
| Race conditions (TOCTOU) | Make check and use one atomic operation |
| Information leakage in errors | Generic messages to users; details in protected logs |
Secure coding practices
- Validate input on the server, using allow lists where possible.
- Encode output for the context it goes into.
- Use parameterized queries for all database access.
- Fail securely: deny when a security check cannot complete; roll back failed transactions; clear sensitive buffers on error paths.
- Least privilege for application accounts.
- No hard-coded secrets; use secrets managers.
- Use vetted libraries for cryptography and authentication rather than writing your own.
Reference resources
| Resource | Use |
|---|---|
| OWASP Top 10 | Awareness of the most critical web application risk categories |
| OWASP ASVS | Verifiable security requirements for testing applications at defined levels |
| CERT secure coding standards | Language-specific rules (for example C, C++ and Java) |
| CWE | Common Weakness Enumeration: a catalog of weakness types |
| BSIMM | Describes practices observed in real organizations, for comparison |
The OWASP Top 10 raises awareness; it is not a complete standard. Use ASVS when you need testable requirements.
API security
APIs expose functionality directly, so they need authentication (for example OAuth 2.0 tokens), authorization on every call (object-level checks), input validation, rate limiting, encryption in transit, and inventory so no forgotten API remains exposed.
Software-defined security
Security policy expressed as code: infrastructure as code with security checks, policy as code for access and configuration, and automated guardrails in cloud and container platforms. It makes controls repeatable and testable, but the code itself needs review and protection.
Enforcing standards
Automated checks (static analysis rules that fail builds, dependency and secret scanning) enforce standards on every change. Training and peer review support them. Periodic attestations or annual penetration tests alone cannot catch each commit.
How the exam asks about this
- "Which remediation does a coding standard require for SQL injection?" Parameterized queries.
- "Authorization service unreachable." Deny the request until it can be evaluated.
- "Which resource lists verifiable requirements for testing applications?" OWASP ASVS.
What to remember for the exam
- Know the standard fix for each common weakness.
- Validate input, encode output, parameterize queries, fail securely.
- OWASP Top 10 for awareness, ASVS for requirements, CERT for language rules, CWE for weakness types.
- APIs need authentication, per-call authorization, validation and rate limiting.
- Enforce standards with automated pipeline checks.
Client-side validation improves usability but provides no security. Attackers bypass the client; validate on the server.
Common mistakes
Escaping input instead of using parameterized queries.
Showing stack traces to users.
Writing custom cryptography.
Check yourself
What is the standard fix for cross-site request forgery?
Anti-forgery tokens, generated per session or per request and validated on the server.
How do you prevent session fixation?
Issue a new session identifier when the user authenticates.
Which resource gives language-specific secure coding rules for C and Java?
The CERT secure coding standards.
Topic 4 of 4 in Software Development Security
Test yourself on Software Development Security
The full ISC2 CISSP question bank has 1,113 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISC2. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.