8.5 Secure Coding Standards & Practices
8.5 Secure Coding Standards & Practices
Secure software should not depend on every developer independently remembering every possible vulnerability.
Organisations reduce software risk by defining repeatable coding rules, approved security patterns, safe APIs and programmable security controls that make common weaknesses harder to introduce.
CISSP 8.5 focuses on four explicit areas: source-code weaknesses and vulnerabilities, API security, secure coding practices, and software-defined security.
The central idea is: prevent predictable weakness patterns during implementation instead of relying only on testing to discover them later.
Know the Weakness
Understand how unsafe source patterns become exploitable vulnerabilities.
RECOGNISE THE PATTERNSecure the Interface
Authenticate, authorize, validate and constrain every API interaction.
EVERY ENDPOINT IS A TRUST BOUNDARYStandardise the Safe Way
Give developers actionable, testable rules and approved security patterns.
MAKE SECURE THE DEFAULTDefine and Apply Secure Coding Guidelines and Standards
The current ISC2 CISSP Exam Outline explicitly contains four subtopics.
Recognise implementation patterns that can create exploitable software weaknesses.
Protect machine-to-machine and application interfaces with strong authentication, authorization, validation, resource controls and secure data handling.
Apply consistent rules and patterns for validation, encoding, authentication, authorization, cryptography, errors, secrets, memory and other implementation concerns.
Express and enforce security capabilities through programmable software, policy and automation rather than relying only on fixed or manually configured controls.
Official 8.5 Topics
Where 8.5 Fits
Integrate security throughout development.
WHEN?
Secure languages, libraries, tools, repositories and testing.
WHERE & WITH WHAT?
Determine whether software-security activities actually work.
DOES IT WORK?
Assess externally supplied software and services.
WHO BUILT / RUNS IT?
Prevent implementation weaknesses through secure rules and patterns.
HOW SHOULD CODE BE WRITTEN?
Weakness vs Vulnerability
A flaw, error or condition in software design or implementation that can contribute to security problems.
Think: CWE category or weakness type.
A weakness present in a real product or system under conditions that create exploitable or otherwise meaningful security exposure.
Think: specific vulnerable implementation.
🧬 CWE vs CVE Weakness type vs specific disclosed vulnerability
A taxonomy of recurring software and hardware weakness types.
Identifies specific publicly disclosed vulnerabilities in real products.
Common Source-Level Weakness Families
Improper validation, unsafe canonicalization and unexpected data reaching sensitive operations.
Untrusted data changes the meaning of SQL, OS commands, code, templates or other interpreters.
Untrusted data is rendered into HTML, JavaScript, URLs or other contexts without appropriate encoding.
The application fails to verify whether the caller may access the requested object, function or property.
Identity verification, token handling, reset flows or session lifecycle are implemented incorrectly.
Out-of-bounds reads/writes, use-after-free and similar lifetime or bounds errors.
Overflow, underflow, truncation or signed/unsigned confusion changes security-sensitive logic or allocation.
Security assumptions change between separate operations performed on shared state.
Unsafe upload, pathname handling, temporary files or permissions expose data or executable content.
Untrusted data is transformed into internal object state through unsafe deserialization mechanisms.
Failures disclose sensitive internals or leave the application in an unsafe state.
Credentials are embedded in source or cryptographic mechanisms are selected/used incorrectly.
Input Validation
Input validation checks whether data has the properties the application expects before the data is trusted or used.
Is this actually an integer, date, identifier, filename or other expected data type?
Is the input within reasonable minimum and maximum sizes?
Is the numeric or temporal value inside permitted bounds?
Does the data conform to the expected structure?
Where practical, accept known valid forms rather than trying to enumerate every malicious form.
A syntactically valid value can still be invalid for the business operation.
Normalize or resolve equivalent representations before security decisions where needed.
Client-side validation improves usability but must not be trusted as the only security control.
Validate vs Sanitize vs Encode
| Control | Question | Example |
|---|---|---|
| Validate | Is this input acceptable? | Customer age must be an integer from 0 to 120. |
| Sanitize | Can unsafe or unwanted elements be transformed or removed safely? | Removing unsupported markup from allowed rich text. |
| Encode | How should data be represented safely in this output context? | HTML-encode untrusted text before inserting it into HTML content. |
Injection
Injection occurs when untrusted data is allowed to change the structure or meaning of instructions sent to an interpreter.
User-controlled data changes a database command.
User-controlled data changes a shell or operating-system command.
User-controlled data becomes executable code or script.
Untrusted data is interpreted by a template or expression engine as instructions.
🗄️ SQL Injection - Think Parameterization Keep data separate from query syntax
Build a SQL statement by concatenating an account number supplied by the caller.
Use a parameterized query or prepared statement so the database receives query structure separately from the untrusted value.
Cross-Site Scripting - XSS
XSS occurs when attacker-controlled data is rendered into browser content in a way that allows it to become executable script or otherwise change the intended page structure.
Encode untrusted data according to the exact destination context.
Prefer frameworks with secure contextual encoding enabled by default.
Reduce use of APIs that interpret strings as HTML or script.
Can provide defense in depth but should not replace correct output handling.
When HTML is intentionally allowed, use a well-maintained allowlist-based sanitizer designed for that purpose.
Whether data is persisted or immediately reflected changes the path, not the fundamental output-trust problem.
Path Traversal & File Handling
Do not allow external path elements to escape the intended storage root.
Resolve path representation carefully before applying security checks where necessary.
Validate expected type/size and treat uploaded content as untrusted.
Avoid storing untrusted uploads where they automatically become executable.
Use server-controlled storage identifiers rather than blindly trusting supplied filenames.
Run file-processing components with only the access they require.
Memory-Safety Weaknesses
Languages that expose direct memory management can permit classes of weakness that are difficult or impossible to express in memory-safe languages.
Code writes before or after the intended memory region, potentially corrupting adjacent state.
Code reads memory outside the intended object and may expose sensitive information or crash.
Input exceeds the capacity of a destination buffer.
Code continues to reference memory after its lifetime has ended.
The same allocation is freed more than once, potentially corrupting memory-management state.
Code dereferences an invalid reference and can cause crashes or unsafe behavior.
🔢 Integer and Numeric Safety Small arithmetic mistakes can become memory and authorization problems
An attacker controls the requested item count. Multiplication used to calculate buffer size wraps around, producing a much smaller allocation than expected.
Race Conditions & TOCTOU
A race condition occurs when security depends on the timing or ordering of operations on shared state.
Untrusted Deserialization
Serialization converts application state into a transportable or storable form. Deserialization reconstructs that state.
Unsafe deserialization can allow untrusted input to create unexpected object types, trigger dangerous code paths or modify sensitive application state.
Use data-oriented formats and explicit schemas rather than arbitrary executable object graphs where possible.
Reject fields, types and values outside the expected schema.
Do not deserialize attacker-controlled objects using mechanisms capable of invoking arbitrary application behavior.
Where serialized state must be trusted, protect authenticity and integrity appropriately.
Authentication, Authorization & Session Security
Establish identity using approved organisational mechanisms rather than ad hoc application-specific schemes where possible.
Check access for every protected resource and action according to the caller's current permissions.
Application and service identities should receive only required permissions.
Use well-reviewed authentication and authorization frameworks rather than repeatedly reimplementing complex security logic.
Generate unpredictable tokens, protect them from disclosure and apply appropriate expiry and invalidation.
Treat recovery flows as authentication flows; tokens should be scoped, protected and appropriately time-limited.
Re-evaluate or invalidate sessions when risk-relevant identity or privilege state changes where required.
Record important authentication and authorization events without recording reusable secrets.
Fail Securely
A failed security mechanism allows the operation.
A failed security decision leaves access denied or the system in another defined safe state.
An authorization service times out. The application should not automatically conclude: "therefore allow access."
Error Handling & Secure Logging
Return enough information to recover or report the problem without exposing internal implementation details.
Preserve useful diagnostic context in protected logs or monitoring systems.
Do not expose raw stack traces, internal paths or database errors to unauthorized users.
Do not log passwords, private keys, full session tokens or unnecessary sensitive personal data.
Record authentication failures, authorization failures, input-validation failures and security-relevant administrative actions where appropriate.
Centralized error and logging components reduce inconsistent security behavior.
Secrets Management
Avoid embedding reusable credentials in source, binaries, container images or ordinary configuration files.
A secret should grant only the access required by the application.
Design applications so credentials can be changed without rewriting source code.
Avoid printing secrets in logs, errors, crash dumps or telemetry.
Development credentials should not automatically grant production access.
Where platforms support it, short-lived identity-based credentials can reduce dependence on static secrets.
Cryptographic Practices
Follow organisational and regulatory cryptographic requirements rather than choosing algorithms informally.
Prefer well-reviewed cryptographic APIs and protocols rather than implementing primitives yourself.
Protect generation, storage, access, rotation, backup and destruction of keys.
Use cryptographically suitable randomness for keys, tokens, nonces and security-sensitive identifiers.
Use appropriate password hashing mechanisms rather than reversible encryption or fast general-purpose hashes.
Use approved modern TLS configurations rather than custom encryption protocols.
Crypto Coding Memory Aid
API Security
APIs expose application functionality to other applications, services, devices and automation.
Every API endpoint should be treated as a security boundary where identity, authorization, input, resource use and data exposure must be controlled.
Who is calling?
May this caller access this specific record or object?
May this caller invoke this operation?
Which fields may this caller read or modify?
Is the request structurally and semantically valid?
Return only information the caller is authorized and needs to receive.
Limit request size, frequency, processing cost and other abuse paths.
Know which endpoints, versions and environments are exposed.
API Request Memory Aid
Broken Object Level Authorization - BOLA
Customer A legitimately accesses: /accounts/123
Customer A changes the identifier to: /accounts/124
If the API returns another customer's account because it trusts the identifier without checking ownership or permission, object-level authorization is broken.
Object vs Property vs Function Authorization
| Question | Authorization Level |
|---|---|
| May this user access customer record 123? | Object Level |
| May this user change the customer's riskRating property? | Object Property Level |
| May this user invoke /admin/deleteCustomer? | Function Level |
Unrestricted Resource Consumption
API requests can consume:
Constrain request frequency where appropriate.
Bound request bodies, uploads, page sizes and response sizes.
Constrain expensive queries and recursive/graph operations.
Limit per-user, per-client or per-tenant consumption where needed.
Avoid unbounded operations and resource retention.
Some sensitive workflows need additional anti-automation or anti-abuse controls beyond generic rate limiting.
Server-Side Request Forgery - SSRF
SSRF occurs when an application makes network requests to destinations influenced by an attacker without adequately restricting what the server may access.
Restrict outbound requests to required hosts/protocols where feasible.
Consider redirects, DNS behavior and alternate address representations.
Limit what application workloads can reach.
Do not assume internal endpoints are safe merely because they are not Internet-facing.
API Inventory & Version Management
An organization cannot secure an API it does not know still exists.
Track exposed APIs, owners, versions and environments.
Remove obsolete endpoints rather than leaving forgotten attack surface indefinitely.
Maintain enough current interface documentation for developers and security teams to understand expected behavior.
Avoid accidentally exposing development, debug or test endpoints to production users.
Ensure legacy versions do not bypass modern authentication requirements.
Detect traffic to deprecated or unknown interfaces so hidden dependencies can be identified before shutdown.
🔄 Third-Party APIs Are Untrusted Input Too Your server receiving the data does not make the data trustworthy
Applications often trust partner or vendor APIs more than end-user input.
That trust can be misplaced if the upstream service is compromised, misconfigured or returns unexpected data.
What Makes a Good Secure Coding Standard?
Rules should describe an observable coding requirement rather than vague advice such as 'be careful with input'.
Developers should know which secure pattern or approved API to use.
Standards should reflect the technology being used; C memory rules differ from JavaScript output-encoding rules.
Code review, linting, SAST or tests should be able to verify important rules where practical.
Prioritize rules that prevent serious and likely weakness classes relevant to the organisation.
Update standards when languages, frameworks, threat patterns and platform capabilities change.
Reference the standard in developer tooling, pull-request checks, training and reusable components.
Someone must be accountable for maintaining the secure-coding rules and approved patterns.
Standard vs Guideline
Defines mandatory or required coding rules within the organisation.
Database queries containing untrusted values must use the approved parameterized-query interface.
Provides recommended practices, patterns or implementation advice.
Prefer framework-provided contextual encoding helpers rather than manual escaping.
Where Organisations Get Coding Rules
Broad web/application coding checklist covering validation, encoding, authentication, sessions, access control, cryptography, errors, data protection, databases, files, memory and general practices.
Language-specific secure coding rules for technologies such as C and C++.
Weakness taxonomy that helps map recurring implementation mistakes into categories.
High-level secure development framework that recommends using secure coding practices and reviewing/analyzing code.
Secure patterns published by language, framework and platform maintainers can supplement organisational rules.
Incidents, vulnerabilities and recurring defects should feed back into organisation-specific secure-coding standards.
Do Not Make Every Developer Reinvent Authentication
Eighty microservices each contain separately written: JWT validation, role checks and session logic.
A vulnerability is fixed in 47 services but missed in the others.
Secure Coding Design Memory Aid
Software-Defined Security
ISC2 lists software-defined security as an 8.5 topic but does not provide examples in the exam outline.
A useful way to understand the concept is: security policy and enforcement can be represented, configured and changed through software and APIs rather than being tied only to fixed hardware or manual configuration.
Security configuration and policy can be version-controlled, reviewed and deployed like other code.
Machine-readable policy can drive automated authorization, compliance or configuration decisions.
Programmable controllers and APIs can create network segmentation and policy dynamically.
Security groups, workload policies, identity rules and service configuration can be managed programmatically.
Security-relevant infrastructure settings can be defined and reviewed before automated deployment.
Software can apply context-aware security decisions based on identity, workload, resource or runtime state.
Security as Code - Why It Helps
The same reviewed policy can be applied repeatedly across many systems.
Version control can show what changed, when and why.
Approved policy can be deployed rapidly without manual reconfiguration.
Policy behavior can be validated before broad deployment.
Software-defined controls can support large dynamic cloud and microservice environments.
Versioned configurations can support controlled reversal when changes fail.
⚙️ Automation Amplifies Mistakes Too One policy bug can become 5,000 insecure systems
A developer changes a network policy from: approved corporate ranges to all Internet addresses.
Automated deployment applies the change to thousands of workloads.
🤖 Modern Consideration - AI-Assisted Coding Generated code still needs secure coding controls
AI-assisted development can increase productivity, but generated code can contain:
🧠 45 CISSP Practice Scenarios Source weaknesses, APIs, coding practices and software-defined security
A web form accepts a customer age of -900 and passes it directly to business logic.
Which secure-coding principle is missing?
Validate input against the application's expected type, range and business rules.
A developer checks that an input contains only digits, then later concatenates it into a SQL statement.
Best secure-coding approach?
Use parameterized queries or prepared statements rather than relying on input validation alone to prevent SQL injection.
User-supplied text is safely stored in the database but later rendered into HTML without context-appropriate encoding.
Which weakness may result?
Cross-site scripting - output should be encoded for the context in which it is rendered.
An application removes the string '../' once from a file path but then processes a differently encoded traversal sequence.
What principle is relevant?
Canonicalize and validate paths carefully; naive sanitization is not a reliable substitute for safe path handling.
A program builds an operating-system command by concatenating a filename supplied by a user.
Primary risk?
OS command injection.
A service interprets user-controlled text as executable code.
Primary risk?
Code injection; do not treat untrusted data as executable instructions.
A program copies attacker-controlled data into a fixed-size memory buffer without checking bounds.
Which source-level weakness?
Buffer overflow / out-of-bounds write.
Code continues to use a pointer after the memory it references has already been freed.
Which weakness?
Use-after-free.
Two threads check and then modify a security-sensitive file, allowing the state to change between the check and the use.
Which class of weakness?
Race condition / time-of-check to time-of-use weakness.
An application deserializes an attacker-supplied object using an unsafe framework feature.
Primary concern?
Deserialization of untrusted data can trigger unintended object creation or code paths.
A file-upload function trusts the filename extension and stores uploaded files inside an executable web directory.
Best security direction?
Validate content/type, rename safely, store outside executable paths where appropriate and apply strict authorization and processing controls.
The application returns a full stack trace, SQL query and internal file path to an unauthenticated user.
Which coding practice is weak?
Error handling should avoid exposing sensitive internal details.
Passwords, private keys and cloud tokens are hard-coded in source code.
Better practice?
Keep secrets out of source and retrieve them through appropriately protected secret-management mechanisms.
A developer creates a custom encryption algorithm because it is shorter than using an approved library.
CISSP answer?
Use well-established, reviewed cryptographic libraries and approved algorithms rather than inventing cryptography.
A security-sensitive operation accepts any authenticated user without checking whether that user is authorized for the specific action.
Which weakness?
Missing or incorrect authorization.
A customer changes /accounts/123 to /accounts/124 and receives another customer's data.
Which API weakness?
Broken Object Level Authorization - BOLA / IDOR-style authorization failure.
An API checks authentication at login but never validates object-level authorization on individual resource requests.
Best fix?
Perform authorization checks for each protected object/action, not only at initial authentication.
An API accepts a JSON object containing an 'isAdmin' property and blindly maps every supplied property into the user record.
Which API concern?
Broken object property level authorization / mass-assignment-style weakness.
An unauthenticated API endpoint can trigger thousands of expensive password-reset SMS messages per minute.
Which API risk?
Unrestricted resource consumption and abuse of costly business operations; apply appropriate limits and controls.
A normal user discovers an undocumented administrative API endpoint and can invoke it.
Primary problem?
Broken function-level authorization plus poor API inventory/governance.
An API fetches any URL supplied by the caller, including internal cloud metadata addresses.
Which risk?
Server-Side Request Forgery - SSRF.
A service trusts data returned by a third-party API and passes it directly into a database query.
Which lesson?
External APIs are also untrusted input; validate, constrain and safely process their data.
An API returns every field in a customer object, including internal risk flags not intended for the caller.
Which security issue?
Excessive data exposure / broken object property level authorization.
An API token is placed in the URL query string and appears in browser history and proxy logs.
Better design?
Use protected authorization headers or another appropriate mechanism and avoid leaking secrets through URLs and logs.
An API uses a predictable sequential identifier but enforces correct authorization on every request.
Is predictability alone the vulnerability?
Not necessarily. Predictable IDs increase discoverability, but the critical control is correct authorization.
A developer assumes that HTTPS means request input does not need validation.
Correct principle?
TLS protects transport; it does not make untrusted application input trustworthy.
A developer 'sanitizes' input by deleting apostrophes and assumes SQL injection is solved everywhere.
Better approach?
Use parameterized queries and context-appropriate controls; ad hoc sanitization is fragile.
A template engine supports automatic contextual output encoding, but the developer disables it to render raw HTML from users.
Primary concern?
The developer has bypassed a safe default and may introduce XSS.
An application performs authentication correctly but logs complete session tokens for troubleshooting.
Which secure-coding principle is violated?
Do not place sensitive authentication/session secrets in logs.
A password-reset token is long and random but never expires and can be reused.
What else is needed?
Security-sensitive tokens should have lifecycle controls such as expiry and single-use semantics where appropriate.
A security check fails because a dependency service is unavailable. The application responds by allowing the requested action.
Which design principle?
Fail securely - security-control failure should not silently become authorization.
A service account used by the application has database administrator rights even though it only needs read access to two tables.
Which principle?
Least privilege.
A developer catches every exception with one empty handler so the application never crashes.
Security problem?
Suppressing errors can hide security failures and leave the system in an unsafe or inconsistent state.
An application accepts arbitrary regex supplied by users and evaluates it against very large input, causing extreme CPU use.
Which coding concern?
Resource-exhaustion / algorithmic complexity should be constrained.
A C program increments a size value that wraps around before memory is allocated.
Which weakness family?
Integer overflow/wraparound can lead to incorrect allocation and memory-safety failures.
A secure-coding rule says developers 'should be careful with input' but gives no testable requirement.
How can the standard improve?
Make rules specific, actionable and verifiable, with approved patterns or examples.
A team copies the same authorization code into 80 services and fixes are applied inconsistently.
Better secure-coding strategy?
Use centrally maintained, reviewed security components or frameworks where appropriate rather than duplicating fragile security logic.
Security policy is stored as version-controlled code, reviewed through pull requests and automatically deployed to enforcement points.
Which official 8.5 concept does this illustrate?
Software-defined security - security policy/enforcement represented and managed through software.
A cloud firewall rule is generated automatically from code and a one-line change could expose every service to the Internet.
Main lesson?
Software-defined security enables consistency and automation, but code changes to security policy require the same strong review, testing and least-privilege controls.
A policy-as-code rule is incorrect and automation deploys it consistently to 5,000 workloads.
What does this demonstrate?
Automation scales both correct and incorrect security decisions; validation and controlled change remain essential.
An AI coding assistant generates a convenient authentication function copied into production without review.
CISSP secure-development response?
AI-generated code should be treated as untrusted development output and reviewed/tested against the same secure-coding standards as human-written code.
A team eliminates a SQL injection finding but the same unsafe concatenation pattern remains in dozens of other modules.
Best mature response?
Fix the instance and address the insecure coding pattern systematically through standards, reusable controls, review and testing.
Which four subtopics are explicitly listed in current CISSP 8.5?
Answer?
Source-code weaknesses and vulnerabilities, API security, secure coding practices, and software-defined security.
What is the difference between a weakness and a vulnerability?
Best answer?
A weakness is a type of flaw or condition; a vulnerability is an instance in a real product that can be exploited or otherwise creates security exposure.
Management asks for the central purpose of CISSP 8.5.
Best answer?
Define and apply coding rules and programmable security patterns that prevent common source-level and API weaknesses rather than relying only on finding vulnerabilities after software is built.
Recognise the Clue Words
Untrusted Input
Check type, length, range, format and meaning.
Input ValidationData Used in SQL
Keep data separate from query syntax.
Parameterized QueryUser Data Rendered to HTML
Protect the output context.
Output EncodingUser Input Builds Shell Command
Data becomes command syntax.
Command InjectionUser Input Becomes Code
Data becomes executable logic.
Code Injection../ or Encoded Path
File escapes intended directory.
Path TraversalFixed Buffer + Unchecked Length
Memory corruption.
Buffer OverflowMemory Used After Free
Dangling lifetime.
Use-After-FreeCheck Then Use
State changes between operations.
TOCTOU / Race ConditionUnsafe Object Deserialization
Untrusted object graph.
Deserialization WeaknessHard-Coded Password / Key
Secret in source.
Secrets ManagementCustom Encryption Algorithm
Do not invent crypto.
Approved Crypto LibraryFull Stack Trace to User
Internal detail exposure.
Secure Error HandlingAuthenticated But Not Authorized
Identity is not permission.
AuthorizationChange Object ID
Access another user's object.
BOLA / IDORUser Controls Object Properties
Sensitive field update.
Property-Level AuthorizationUnlimited Expensive API Calls
DoS / financial abuse.
Resource ConsumptionHidden Admin Endpoint
Privileged function.
Function-Level AuthorizationAPI Fetches User URL
Server makes attacker-chosen request.
SSRFOld / Forgotten Endpoint
Unknown attack surface.
API InventoryThird-Party API Response
External data is untrusted.
Unsafe API ConsumptionSecurity Rules Stored as Code
Programmable enforcement.
Software-Defined SecuritySecurity Policy in Pull Request
Versioned security configuration.
Policy / Security as CodeGenerated Code
Source origin does not remove review need.
Apply Same Secure Coding Standard⚠️ Common CISSP Mistakes Secure coding is about precise controls, not slogans
Validation determines whether input satisfies expected rules. Sanitization transforms data. They solve different problems and should not be used interchangeably.
Parameterized queries or equivalent safe APIs should keep untrusted data separate from SQL syntax.
A transformation safe for one context may be unsafe in another.
Encoding protects data when it enters a specific output context; validation checks whether input is acceptable.
Security controls are context-specific.
Knowing who a user is does not determine what that user is permitted to do.
Unpredictable identifiers can reduce guessing but do not replace authorization checks.
TLS protects data in transit but does not fix authorization, injection, business-logic or resource-abuse flaws.
Gateways can enforce useful controls, but application-specific authorization and business logic still require secure implementation.
Limiting request volume does not determine whether a caller is permitted to perform the action.
The application should fail safely and preserve useful internal diagnostic evidence without disclosing sensitive details to users.
Logs can expose passwords, tokens, personal data and cryptographic material if developers do not control content.
Cryptographic algorithms and protocols are easy to get wrong; use established, reviewed mechanisms.
Hashing is generally one-way; encryption is reversible with the appropriate key.
Base64 and similar encodings do not provide confidentiality.
Secrets embedded in source are difficult to rotate safely and may persist in repository history.
Parameterized SQL protects query structure, but business validation and authorization are still necessary.
Memory safety reduces important classes of defects but not authorization, injection, logic or configuration weaknesses.
Testing tools can miss logic and design flaws; secure coding standards remain necessary.
CWE describes weakness types. CVE identifies specific publicly disclosed vulnerabilities.
OWASP risk lists help prioritize awareness; a secure-coding standard should provide concrete rules and approved patterns.
Prefer reviewed, centrally maintained security libraries and frameworks where appropriate.
Security-control failures should not silently grant access unless the risk and design explicitly justify that behavior.
Programmable controls can propagate secure or insecure policy at machine speed.
8.2 secures the development ecosystem and performs AppSec testing. 8.5 focuses on coding rules, source-level weaknesses, API security and software-defined security.
Quick Reference
| If you see... | Think... |
|---|---|
| Type / length / range / format checks | Input Validation |
| Data separated from SQL syntax | Parameterized Query |
| User data placed into HTML safely | Contextual Output Encoding |
| Attacker input changes SQL syntax | SQL Injection |
| Attacker input changes OS command | OS Command Injection |
| Attacker input becomes executable code | Code Injection |
| ../ escapes intended directory | Path Traversal |
| Unchecked write beyond buffer | Out-of-Bounds Write / Buffer Overflow |
| Reference after memory released | Use-After-Free |
| State changes between check and use | Race / TOCTOU |
| Unsafe attacker-controlled object graph | Insecure Deserialization |
| Secret embedded in repository | Hard-Coded Credential |
| Internal stack trace shown externally | Information Exposure / Error Handling |
| User authenticated but cannot access object | Authorization |
| Changing object ID accesses another record | BOLA / IDOR |
| Sensitive property can be modified | Property-Level Authorization |
| Unlimited expensive requests | Resource Consumption / Rate Controls |
| Privileged API endpoint callable by ordinary user | Function-Level Authorization |
| Server fetches attacker-chosen URL | SSRF |
| Forgotten API version still exposed | API Inventory Management |
| Trusting third-party API blindly | Unsafe API Consumption |
| Security policy stored/versioned as code | Software-Defined Security |
| Security configuration automatically deployed | Security / Policy as Code |
| Weakness taxonomy | CWE |
| Specific disclosed vulnerability | CVE |
Four Official 8.5 Topics
8.5 Master Memory Aid
Treat data as data, enforce authorization everywhere, make the secure pattern the easy pattern.
The Secure Coding Leader's Questions
Software Development Security - The Whole Picture
| Objective | Core Question | Think... |
|---|---|---|
| 8.1 | When and how does security enter development? | Secure SDLC |
| 8.2 | Which development technologies and tests must be secured? | Ecosystem + AppSec testing |
| 8.3 | How do we know software security actually works? | Evidence + risk + mitigation |
| 8.4 | What if somebody else built or operates it? | Acquired software + third parties |
| 8.5 | How should implementation avoid predictable weaknesses? | Secure coding + APIs + programmable security |
Domain 8 Memory
Key Takeaways
CISSP 8.5 is: Define and apply secure coding guidelines and standards.
The current ISC2 outline explicitly includes four areas: security weaknesses and vulnerabilities at the source-code level, API security, secure coding practices and software-defined security.
The central principle is: prevent predictable implementation weaknesses by giving developers safe, repeatable patterns rather than relying only on testing after the code is written.
A weakness is a type of software flaw or unsafe condition.
A vulnerability is a weakness present in a real product or system in circumstances that create exploitable or meaningful security exposure.
CWE is a taxonomy of weakness types.
CVE identifies specific publicly disclosed vulnerabilities.
Secure coding begins with understanding trust boundaries and untrusted data.
Input should be validated against the application's expected type, length, range, format and business meaning.
Client-side validation improves usability but cannot be trusted as the only security control because the client is outside the server's trust boundary.
Validation, sanitization and output encoding are different.
Validation asks: is this input acceptable?
Sanitization transforms data to remove or alter unwanted content.
Output encoding asks: how should this data be represented safely in this exact destination context?
There is no universal sanitization step that makes arbitrary input safe for SQL, HTML, JavaScript, shell commands, URLs and every other interpreter.
Injection occurs when untrusted data changes the intended meaning of instructions.
SQL injection should normally be prevented by keeping query structure and untrusted values separate through parameterized queries or equivalent safe database APIs.
Removing apostrophes from input is not a robust general SQL-injection strategy.
OS command injection occurs when user-controlled data changes an operating-system command.
Avoid invoking shell commands with attacker-controlled text where safer APIs exist.
Code injection occurs when attacker-controlled data becomes executable code.
Treat untrusted input as data - not instructions.
XSS is fundamentally an output-context problem.
Untrusted data rendered into HTML, JavaScript, CSS, URLs or other contexts requires appropriate context-sensitive handling.
Framework auto-escaping and contextual encoding should normally remain enabled.
Content Security Policy can provide useful defense in depth but does not replace correct output handling.
Path traversal occurs when attacker-controlled path elements cause access outside the intended directory.
Canonicalization and safe path construction matter because the same path may have multiple textual representations.
File uploads should be treated as untrusted content.
Validate size and expected type, control storage location and permissions, and avoid automatically executing uploaded content.
Memory-safety weaknesses include out-of-bounds access, buffer overflow and use-after-free.
Safer languages and bounds-aware APIs can eliminate or reduce important classes of memory corruption.
But: memory-safe language ≠ vulnerability-free application.
Authorization, injection, business logic and cryptographic misuse remain possible.
Integer overflow, truncation and signed/unsigned conversion can corrupt security logic and memory-allocation calculations.
Validate numeric ranges before sensitive arithmetic and use safe language mechanisms where available.
Race conditions occur when security assumptions change between operations on shared state.
Time-of-check-to-time-of-use is a classic example: the state checked may no longer be the state used.
Unsafe deserialization can transform attacker-controlled data into dangerous internal object state or code paths.
Prefer constrained data formats and explicit schemas over arbitrary executable object graphs when possible.
Authentication and authorization are different.
Authentication answers: who are you?
Authorization answers: what are you allowed to do?
A user should be authorized for the specific object, function and relevant properties being accessed.
Session and reset tokens are security credentials.
Generate them unpredictably, protect them from disclosure and implement appropriate expiry, invalidation and single-use semantics.
Applications should fail securely.
An authorization-service error should not automatically mean: "allow the request."
Error handling should protect internal information while preserving useful diagnostic evidence for authorized operators.
Stack traces, database errors, file paths and sensitive configuration should not be exposed indiscriminately to users.
Logging is part of secure coding.
Record useful security events without placing passwords, private keys, full session tokens or other reusable secrets in logs.
Secrets should not be hard-coded into source.
Use protected secret-management or workload-identity mechanisms so credentials can be scoped, rotated and revoked independently of application source.
Cryptography should use approved, well-established algorithms, protocols and libraries.
Do not invent cryptography to save development effort.
Correct cryptographic algorithms can still be used insecurely when keys, nonces, randomness, protocol versions or certificate validation are handled incorrectly.
API security is explicitly part of 8.5.
APIs expose business functions and data across trust boundaries.
Every protected API request should consider identity, object authorization, function authorization, property authorization, input validation, resource use and output data.
Broken Object Level Authorization occurs when a caller can manipulate an object identifier and access a resource they do not own or are not authorized to use.
Therefore: knowing an object identifier ≠ authorization.
Random identifiers can make guessing harder but must not replace authorization checks.
Object property authorization controls which fields a caller may read or modify.
Function-level authorization controls whether the caller may invoke a privileged operation.
API resource consumption should be bounded.
Attackers can abuse CPU, memory, database connections, storage, email/SMS services, third-party API fees and expensive compute operations.
Rate limits, quotas, size limits, timeouts and business-flow controls can reduce these risks.
SSRF occurs when a server makes attacker-influenced requests to destinations the attacker should not be able to reach through that server.
Restrict outbound destinations and combine application validation with network-level egress controls where appropriate.
API inventory matters.
Forgotten, debug and obsolete endpoints can become unmanaged attack surface.
Retire unused API versions and monitor use of deprecated interfaces.
Third-party API responses should also be treated as untrusted data.
A trusted business partner can still be compromised or return malformed and malicious data.
HTTPS protects transport.
It does not make API input trustworthy and does not solve authorization or business logic.
A secure coding standard should be specific, actionable, technology-aware, testable, maintainable and owned.
Vague advice such as: "validate input carefully" is less useful than a rule describing exactly which validation and safe APIs are required.
Secure coding rules should be integrated into code review, developer training, automated analysis and reusable frameworks where practical.
Developers should not reimplement complex security mechanisms independently in every service if a well-maintained, reviewed shared component is suitable.
Central security libraries can improve consistency and make future remediation easier.
Software-defined security is also explicitly part of 8.5.
ISC2 does not provide examples in the current exam outline.
The useful concept is that security policy and enforcement can be expressed, orchestrated and changed through software and APIs.
Examples can include security-as-code, policy-as-code, programmable network policy, cloud security configuration and infrastructure-as-code security controls.
These examples illustrate the concept; they are not additional official 8.5 bullets.
Software-defined security can improve consistency, auditability, version control and automated deployment.
But: automation ≠ correctness.
An insecure policy can be deployed to thousands of systems more quickly than a human administrator could misconfigure them manually.
Security policy code therefore requires controlled change, review, testing, least privilege, auditability and rollback.
AI-generated code should be treated like other externally generated development output.
It should follow the same secure coding standards, review and testing as human-written source.
Remember the complete Domain 8 sequence:
8.1 = integrate security through the lifecycle.
8.2 = secure the development ecosystem and perform AppSec testing.
8.3 = assess whether software security is effective.
8.4 = assess security impact of acquired software.
8.5 = define and apply secure coding guidelines and standards.
The central CISSP principle for 8.5 is:
treat all external data as untrusted until validated, keep data separate from executable instructions, authorize every protected operation, use proven security libraries and patterns, make secure behavior the default, and review programmable security controls with the same discipline as application code.
📚 Sources & Further Reading Current secure coding, API and software-defined security references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - OWASP Secure Coding Practices - Quick Reference Guide
View OWASP secure coding guidance - OWASP API Security Project - API Security Top 10 2023
View OWASP API Security guidance - MITRE - Common Weakness Enumeration - CWE
View the CWE weakness taxonomy - MITRE - 2025 CWE Top 25 Most Dangerous Software Weaknesses
View the current CWE Top 25 - SEI CERT C and C++ Coding Standards
View SEI CERT secure coding standards - NIST SP 800-218 - Secure Software Development Framework - SSDF Version 1.1
View NIST SSDF - NIST SP 800-231 - Bugs Framework
View NIST software-bug classification guidance - NIST SP 800-228 - Guidelines for API Protection for Cloud-Native Systems
View NIST API protection guidance - NIST NCCoE DevSecOps - Security as Code
View NIST DevSecOps security-as-code guidance - NIST OSCAL - Policy as Code and Machine-Readable Security Controls
View NIST OSCAL