1.
Prompt Injection
Prompt injection is a type of cybersecurity exploit that targets large language models
(LLMs) by manipulating user input to cause unintended behavior or generate
unauthorized outputs. Attackers craft deceptive prompts that can trick the LLM into
revealing sensitive information, executing malicious commands, or bypassing safety
mechanisms. For example, a user may include instructions in their input to override the
system prompt, extract confidential data, or make the model perform malicious tasks.
Prompt injections are similar to SQL injections, as both attacks send
malicious commands to apps by disguising them as user inputs. The key
difference is that SQL injections target SQL databases, while prompt
injections target LLMs.Some experts consider prompt injections to be more
like Social Engineering because they don't rely on malicious code. Instead,
they use plain language to trick LLMs into doing things that they otherwise
wouldn't.
Threat Classification
OWASP Category: AI-specific (Emerging category; not part of OWASP Top 10
yet)
Severity: High
CVSS Base Score (Estimated): 7.5 - 9.0 depending on implementation and
exposure
Attack Vector: Indirect (via user input), Remote
Risk and Impact
Unauthorized control over LLM behavior
Leakage of sensitive data or system instructions
Execution of unintended actions (e.g., impersonation, data exfiltration)
High impact in customer-facing AI or chatbot solutions
How to Fix / Recommendations
Input Validation and Sanitization : Ensuring that all inputs are checked and
cleaned before processing. This involves using allowlists and denylists to filter
out harmful data and employing libraries that offer robust sanitization
functions
Use Prompt Escaping: Escape user input properly to prevent it from being
interpreted as part of the prompt logic.
Separate User Data from Instructions: Structure prompts using strict templates
or formats (e.g., key-value JSON) to distinguish user data from commands.
Secure Prompt Engineering : System prompts with security in mind by
incorporating techniques such as prompt partitioning. This ensures user
inputs are kept separate from the control logic, reducing the likelihood of
malicious prompts being executed.
Sandboxing and Isolation Techniques : Using sandbox environments to
execute untrusted code and isolate different processes. This limits the
potential impact of a successful injection, preventing it from affecting the
entire system.
2. HTML Injection
HTML injection is a security vulnerability where attackers insert malicious
HTML code into a web application, potentially altering the page's appearance
and functionality. This can lead to various consequences, including data
theft, phishing attacks, and even malware distribution. To prevent HTML
injection, it's crucial to validate and encode user-supplied data before
rendering it in the browser.
While HTML Injection is sometimes confused with Cross-Site Scripting (XSS),
the key distinction is that HTML Injection focuses on structural
manipulation rather than JavaScript execution. However, HTML
Injection can escalate to XSS if the application allows <script> tags or
JavaScript event handlers.
Example:
An attacker might inject a <script> tag containing malicious JavaScript code
or a <img src="malicious_url" onerror="alert('XSS')"> tag to trigger an alert
box. This could be used to redirect users to a phishing site or steal their
session cookies.
Threat Classification
OWASP Category: A7:2021 – Cross-Site Scripting (XSS)
Severity: High (especially if script injection is possible)
CVSS Base Score (Estimated): 6.1 – 8.8 depending on context
Attack Vector: Web-based (User Input → HTML Output)
Risk & Impact
Risk Area Description
User Attackers can manipulate the appearance of the
Interface website (e.g., defacement, fake elements).
(UI)
Brand Modified UI can mislead users, show offensive
Reputation content, or impersonate trusted UI elements, leading
to loss of trust.
Phishing / Injected HTML may mimic legitimate elements (e.g.,
Fraud login forms) to trick users into entering credentials.
Cross-Site If JavaScript is accepted via HTML attributes or tags,
Scripting HTML Injection can escalate into a full XSS attack.
(XSS)
Data Manipulated forms or inputs could lead to incorrect
Integrity data processing, corruption, or submission of false
data.
Security Reveals improper use of rendering engines or
Misconfigu insecure handling of user-generated content.
ration
Compliance Exposure to stored or reflected malicious
Risk content may breach GDPR, HIPAA, or other
regulations regarding user safety.
How to Fix / Recommendations
Input Validation : Input validation is the process of
checking user-submitted data to ensure it is valid and conforms to
certain rules. This can help prevent HTML injection attacks by
blocking the submission of malicious HTML code
HTML encoding : HTML encoding is the process of
converting HTML characters, such as < and >, into their
corresponding character entities, such as < and > . This can
help prevent HTML injection attacks by ensuring that user-
submitted data is treated as plain text rather than HTML code.
Content Security Policy (CSP) : CSP is a security
feature that allows websites to specify which sources are allowed to
load resources, such as JavaScript, CSS, and images. By using CSP,
websites can prevent the execution of malicious HTML code that is
injected into the page.
Regular updates: Regularly updating software and plugins
can help prevent HTML injection attacks by fixing vulnerabilities
that attackers may exploit.
3. Java Stack Trace Error Disclosure
Java Stack Trace Error Disclosure is a vulnerability that occurs when
internal server errors and exception messages (stack traces) are returned to
the user through the web interface or API responses. These stack traces
often reveal:
Application logic paths
Java package and class names
Method call sequences
Exact file names and line numbers
Third-party libraries and framework versions
While this information may seem harmless, it offers attackers detailed
insight into the application's inner workings, allowing them to develop
targeted attacks. This vulnerability is typically found in web applications
where errors are not properly handled or where debugging is enabled in
production.
Threat Classification
OWASP Category: A9:2017 – Insufficient Logging & Monitoring (also
related to A6: Security Misconfiguration)
Severity: Medium to High (context-dependent)
CVSS Base Score (Estimated): 5.3 – 7.5
Attack Vector: Remote (via browser or API interaction)
Risk & Impact
Risk Area Description
Informatio Reveals sensitive backend implementation details such as
n classes, methods, file paths, and logic flow.
Disclosure
Exploit Helps attackers craft more precise payloads for
Facilitatio vulnerabilities like RCE, SQL Injection, deserialization, etc.
n
Code Logic Discloses what methods and processes are being called,
Exposure possibly revealing business logic flaws.
Complianc Violates security standards (e.g., ISO 27001, NIST 800-53,
e Violation PCI DSS) by exposing internal system information.
User Trust Exposing raw errors appears unprofessional and can reduce
customer confidence.
Security Indicates poor development or deployment practices (e.g.,
Hygiene lack of QA, running in debug mode).
How to Fix / Recommendations
Suppress Stack Trace Output in Production Environments :
Stack traces should never be exposed to end users. Ensure production
environments are configured to hide error messages and show generic
responses instead.
Implement Centralized Exception Handling : Catch all
unexpected errors and show a generic, non-technical message to users
while logging full details securely for internal use.
Turn Off Debug/Development Modes in Production : Ensure your
application is not deployed in development or debug mode in any
production environment.
Secure Logging Practices :
Log full stack traces only internally using a secure logging
mechanism like Log4j2, SLF4J, or Logback.
Store logs in:
o Centralized log management systems (e.g., ELK, Splunk,
Datadog)
o Locations with appropriate access controls and retention
policies
Never include exception traces in:
o HTTP responses
o UI templates
API responses unless explicitly required for debugging by authorized
developers
4. CORS Misconfiguration (Cross-Origin Resource
Sharing)
CORS (Cross-Origin Resource Sharing) misconfiguration is a security
vulnerability that arises when a web server's CORS policy is not properly
configured, allowing unauthorized cross-origin requests. This can lead to
sensitive data being accessed by malicious actors, potentially resulting in data
theft, cross-site scripting (XSS) attacks, or even remote code execution.
CORS is a browser security feature that controls how a web page can make
requests to a different domain than the one it originated from. It's a mechanism
that allows controlled access to resources on other domains. Without CORS,
browsers would block all cross-origin requests due to the same-origin policy,
which restricts web pages from accessing resources from a different domain than
the one that served the web page.
When a server's CORS policy is misconfigured, it might allow malicious websites
or scripts to access sensitive data from the vulnerable application. For example,
an attacker could use a misconfigured CORS policy to steal user session tokens,
personal information, or even make unauthorized API calls on behalf of a user.
Threat Classification
OWASP Category: A5:2021 – Security Misconfiguration
Severity: High (especially if sensitive APIs are exposed)
CVSS Score (Estimated): 7.4 – 9.0 (depending on data exposure)
Risk & Impact
Risk Area Description
Data Sensitive data (user profiles, account info, tokens) can be
Exposure accessed by malicious domains.
Session If credentials (cookies, JWTs) are allowed and sent cross-
Hijacking origin, an attacker can act as an authenticated user.
Bypassing Attackers may execute state-changing operations if CSRF
CSRF tokens are exposed via CORS.
Protections
Trust Abuse Misconfigured wildcards (*) may allow any domain to
interact with sensitive endpoints.
Browser When combined with XSS or open redirect, CORS
Exploit Chain misconfig can lead to full account takeover.
Compliance Leaking user data across origins may breach regulations
Violation like GDPR, HIPAA, or PCI-DSS.
How to Fix / Recommendations
Use an Explicit Allowlist for Trusted Origins
Only permit known and trusted domains (e.g., your company’s web
applications) to access your backend APIs via CORS.
Never Use Wildcard (*) for Sensitive Endpoints
Avoid using * in the Access-Control-Allow-Origin header for any
endpoints that handle sensitive data, authenticated sessions, or user-
specific operations.
Do Not Allow Credentials with Wildcard Origins
If the Access-Control-Allow-Credentials header is set to true,
make sure the origin is specific and not a wildcard. Wildcards must
never be used with credentialed requests.
Validate Incoming Origin Headers Server-Side
When dynamically setting CORS headers, ensure that the incoming
Origin value is strictly validated against a backend-managed whitelist.
Limit Allowed HTTP Methods and Headers
Restrict CORS to only the HTTP methods (e.g., GET, POST) and
headers (e.g., Content-Type, Authorization) necessary for your
application’s functionality.
Secure Handling of Preflight (OPTIONS) Requests
Configure servers to accept CORS preflight requests only from
approved origins and expected endpoints. Reject any suspicious or
malformed requests.
Disable CORS on Internal or Admin Interfaces
Internal APIs, admin panels, and management consoles should not
accept cross-origin requests under any circumstances.
Regularly Test and Monitor for Misconfigurations
Perform automated and manual security testing for CORS using tools
or scripts. Monitor logs for unexpected origin requests or abuse.
