Secure Coding: OWASP Top 10 & API Security | CISSP Domain 8 | SkillAssess
cisspSoftware Development Security· 11 min read· 21 May 2026
Secure Coding: OWASP Top 10, API Security, and LLM/AI Code Risks (2024 Update)
Secure coding is the practice of writing software in a way that prevents security vulnerabilities from being introduced in the first place. The CISSP exam tests secure coding concepts at the level of a security manager: understanding the major vulnerability categories, knowing the defensive techniques that prevent them, and recognising where new risks (such as AI-assisted coding) are emerging. Domain 8 is one of the most rapidly evolving areas of the CISSP curriculum.
OWASP Top 10: The Most Critical Web Application Vulnerabilities
The OWASP (Open Web Application Security Project) Top 10 is a regularly updated list of the most critical security risks facing web applications. It is the most widely recognised reference for web application security and is tested on the CISSP exam as a framework for understanding application vulnerability categories.
Injection attacks occur when untrusted data is sent to an interpreter as part of a command or query. SQL injection is the most common form: an attacker submits input containing SQL syntax (for example, ' OR '1'='1) that is incorporated directly into a database query, causing the query to return unauthorised data or modify the database. Other injection types include OS command injection, LDAP injection, and XML/XPath injection. The primary defence is parameterised queries (prepared statements) for database interactions, which ensure that user input is always treated as data, never as SQL syntax.
Broken authentication occurs when authentication mechanisms are implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities. Examples include weak password policies, predictable session IDs, missing account lockout, and insecure credential storage (storing passwords in plaintext or with weak hashing).
Insecure Direct Object References (IDOR), now categorised under Broken Access Control in the OWASP 2021 update, occur when an application exposes internal implementation objects (database record IDs, file paths) to users who can manipulate them to access unauthorised resources. For example, changing a URL parameter from account_id=12345 to account_id=12346 might expose another user's account data if the application does not verify authorisation for the requested object.
Security misconfiguration is the most common vulnerability in practice. Examples include default credentials left unchanged, unnecessary features enabled, verbose error messages exposing stack traces, directory listing enabled on web servers, and cloud storage buckets with public read access. Security misconfiguration is addressed through hardening standards, configuration management, and automated configuration scanning.
Cryptographic failures (previously called Sensitive Data Exposure) occur when applications do not adequately protect sensitive data through proper cryptography. Examples include storing passwords without hashing, using deprecated algorithms (MD5, SHA-1 for password hashing, DES for encryption), transmitting sensitive data over HTTP instead of HTTPS, and weak random number generation for session tokens.
Server-Side Request Forgery (SSRF) occurs when an application fetches resources from a URL that the attacker controls. In cloud environments, SSRF can be used to access internal metadata services (such as the AWS EC2 instance metadata service at 169.254.169.254) that contain credentials, enabling an attacker to escalate privileges in the cloud environment.
For the exam: know the top categories at least at the name and concept level. The exam tests whether you can identify which vulnerability category applies in a given scenario and what the primary defensive technique is.
API Security Vulnerabilities
APIs have become the primary interface for modern applications, and they introduce specific security risks that differ from traditional web application vulnerabilities. The OWASP API Security Top 10 documents the most critical API vulnerabilities.
Broken Object Level Authorisation (BOLA), also called Insecure Direct Object Reference (IDOR), is the most common API vulnerability. An API endpoint that returns data based on an object ID (GET /api/invoices/12345) must verify that the requesting user is authorised to access that specific object. If it relies only on authentication (is the user logged in?) without authorisation (is this user allowed to see invoice 12345?), any authenticated user can access any object by manipulating the ID.
Broken Function Level Authorisation occurs when an API fails to restrict access to sensitive functions (administrative operations, payment processing) based on the user's privilege level. An API that exposes /api/admin/users without verifying that the caller is an administrator grants any authenticated user administrative capabilities.
Excessive Data Exposure occurs when an API returns more data than the client needs, relying on the client-side application to filter the response before displaying it. If the full data object is returned and the client simply hides certain fields in the UI, an attacker who calls the API directly receives the unfiltered data including sensitive fields.
Lack of Rate Limiting allows attackers to brute force authentication endpoints, enumerate objects, or perform denial-of-service attacks by making large numbers of requests. Rate limiting should be applied to all API endpoints, with stricter limits on authentication endpoints.
For the exam: API security focuses on authorisation (BOLA, broken function level authorisation), data exposure, and rate limiting. Authentication is necessary but not sufficient — every API call must also verify that the authenticated user is authorised to perform the specific operation on the specific object.
LLM-Assisted Coding Risks: The 2024 Exam Addition
The CISSP 2024 exam outline adds AI and machine learning risks to Domain 8, reflecting the rapid adoption of LLM (Large Language Model) tools in software development. AI coding assistants (GitHub Copilot, Amazon CodeWhisperer, ChatGPT) are now widely used to generate, review, and complete code. This introduces novel security risks.
Hallucinated insecure code is the most direct risk: LLMs generate plausible-looking but incorrect or insecure code with confidence. An LLM may generate a SQL query using string concatenation (vulnerable to SQL injection) when the developer asks for a database interaction, because the model produces code that looks correct based on patterns in its training data without understanding the security implications. Developers who accept LLM suggestions without security review may unknowingly introduce vulnerabilities.
Hallucinated package names occur when LLMs suggest importing non-existent packages. If an attacker creates a real package with that name on a package registry (npm, PyPI) containing malicious code, any developer who follows the LLM's suggestion and installs the package will execute the malicious code. This is called package hallucination or dependency confusion via LLM.
Training data poisoning is an attack where adversaries introduce malicious code examples into the datasets used to train or fine-tune LLMs. If the training data contains code with subtle backdoors or vulnerabilities, the model learns to reproduce these patterns. An LLM trained on poisoned data may consistently suggest vulnerable code patterns.
Prompt injection attacks target LLM-powered applications. When an application incorporates user input into prompts sent to an LLM, an attacker may craft input that manipulates the LLM's behaviour — overriding the application's instructions, extracting confidential information from the LLM's context, or causing the LLM to perform unauthorised actions.
For the exam: LLM coding risks are a 2024 addition. Key risks are hallucinated insecure code (requires security review of LLM output), hallucinated packages (verify all suggested dependencies), and prompt injection (prevent user input from manipulating LLM instructions).
Model Hijacking and Inference Attacks
ML systems used in security applications (fraud detection, anomaly detection, UEBA) are themselves attack targets.
Model inversion attacks attempt to reconstruct training data from a model's outputs. By making many queries to a model and analysing the responses, an attacker may be able to infer sensitive information that was present in the training data.
Adversarial examples are inputs crafted to cause a machine learning model to make incorrect classifications. In security applications, adversarial examples might be used to cause a malware classifier to categorise malicious code as benign, or to cause a fraud detection system to approve fraudulent transactions.
Membership inference attacks determine whether a specific data point was present in a model's training data. In healthcare or financial ML applications, this could reveal whether a specific individual's data was used to train the model.
Input Validation and Output Encoding
Input validation and output encoding are the two most fundamental defensive coding techniques, and the exam tests the distinction between them.
Input validation ensures that all input received by the application conforms to expected formats, types, lengths, and value ranges. Validation should occur server-side (client-side validation is easily bypassed). Validation approach: reject invalid input early (allow-list validation), before it is used in any operation. Input validation prevents injection attacks by ensuring that malicious SQL, HTML, or command syntax is rejected before it can reach an interpreter.
Output encoding ensures that data included in output (web pages, API responses, email) is encoded appropriately for the output context so that it cannot be interpreted as executable code. Output encoding prevents cross-site scripting (XSS) attacks: when user-provided data is included in an HTML page, encoding it (replacing < with <, > with >, etc.) ensures that the browser renders it as text, not as HTML or JavaScript.
The critical exam distinction: input validation prevents malicious input from entering the system. Output encoding prevents data already in the system from being interpreted as code when it is output to a different context. Both are required and they are not interchangeable.
For the exam: parameterised queries prevent SQL injection (not input validation alone). Input validation prevents data from entering the system in an unexpected form. Output encoding prevents stored or reflected data from executing as code in a different context.
Exam Tip
Input validation prevents injection (malicious input rejected at entry). Output encoding prevents XSS (stored data encoded before rendering in HTML). Both are required — neither is a substitute for the other. OWASP Top 10 is the reference framework for web application vulnerabilities. API security adds BOLA (object-level authorisation) and excessive data exposure as common API-specific risks. LLM coding risks are 2024 additions — hallucinated insecure code and prompt injection are the exam-relevant concepts.
// PRACTICE_THIS_DOMAIN
Test your knowledge on Software Development Security
AI-generated practice questions mapped to this domain. Get instant explanations and track your progress.