- 20
- February
In addition to SQL Injection there are two more types of vulnerabilities ranked among the most severe web application threats: Cross-Site Scripting (XSS) which has consistently appeared in the OWASP Top 10, and Prototype Pollution which is a JavaScript-specific vulnerability that is being discovered with increasing frequency — this article explains how both vulnerabilities work and the protection measures that enterprise ERP systems should implement.
What Is Cross-Site Scripting (XSS)?
XSS is an attack where a hacker injects malicious JavaScript code into a web page so that the code executes on another user's browser — as if the code were a legitimate part of the website.
In simple terms: a user opens a trusted website, but the code actually running is the hacker's — without the user ever knowing.
The 3 Types of XSS
| Types | Principles | Danger Level |
|---|---|---|
| Stored XSS | Malicious code is stored in the database (e.g., through a comment field) and rendered every time someone opens that page. | Very high — affects every user who opens that page. |
| Reflected XSS | Malicious code is Embedded in a URL and the server reflects it back for immediate rendering. | Medium — requires tricking the user into clicking a link. |
| DOM-based XSS | Malicious code is processed directly on the browser side. JavaScript reads values from the URL and renders them without going through the server. | Medium — hard to detect because it never passes through the Server. |
What Can XSS Do?
Impact of XSS (if the attack succeeds)
- Steal Session Cookies — the hacker can log in as the victim immediately without knowing the password.
- Keylogging — records everything the victim types on that page (passwords, credit card information).
- Page Defacement — displays fake content such as phishing forms designed to harvest personal information.
- Redirect to Fake Websites — takes the victim to a phishing page without their knowledge.
- Spread Malware — embeds code to download malicious files.
Example Scenario
Suppose a system has an "Employee Search" field on its web page — the user types a name and the system displays results:
Normal scenario:
The user types: Somchai
The system displays: "Search results: Somchai — 3 records found"
Vulnerable scenario:
If the system renders user input directly on the web page without sanitizing or encoding it first —
a hacker can type JavaScript code instead of a name. This causes the victim's browser to execute that code as if it were part of the website.
How to Prevent XSS — 4 Key Strategies
1. Output Encoding
The most important principle: Never render user input directly on a web page — always convert special characters to a safe format first.
| Dangerous Character | Encoded As | Reason |
|---|---|---|
< |
< |
Prevents opening HTML tags |
> |
> |
Prevents closing HTML tags |
" |
" |
Prevents escaping from attributes |
& |
& |
Prevents creating fake entities |
2. Content Security Policy (CSP)
CSP is an HTTP Header that tells the browser "which sources are allowed to load Scripts" — if a hacker injects code, the browser will refuse to execute it.
How CSP works:
- Defines a Whitelist specifying which domains can run Scripts.
- Blocks Inline Scripts (code embedded directly in HTML).
- Prohibits the use of
eval()and functions that create code from strings. - Even if a hacker injects code, the browser will not execute it.
3. Framework Auto-Sanitization
Modern web frameworks such as Angular, React, and Vue have built-in Sanitization systems that automatically filter out malicious code:
- Angular — Automatically sanitizes all values bound to Templates. If HTML tags are inserted, they are converted to plain text.
- React — Uses JSX which escapes values automatically. You must use
dangerouslySetInnerHTMLonly if you truly need to render HTML (the name itself warns of the danger). - Vue — Uses
{{ }}(double curly braces) which escapes automatically. You must usev-htmlonly if you need to render HTML.
4. HttpOnly Cookie
Set session Cookies to HttpOnly — making it so JavaScript cannot read Cookie values. Even if a hacker successfully injects XSS code, they cannot steal the session.
What Is Prototype Pollution?
Prototype Pollution is a vulnerability specific to the JavaScript language, caused by a special mechanism called Prototype Chain
Understanding Prototypes in JavaScript
In JavaScript, every Object has a "blueprint" (Prototype) from which it inherits properties — similar to genetics passed from parents to children.
An easy analogy:
- Imagine every Object in the system is an "employee."
- The Prototype is the "employee template" that defines default properties, such as "system access = none."
- Prototype Pollution occurs when a hacker modifies the template for example, changing it to "system access = Admin" — causing every employee created from this template to instantly become Admin.
Impact of Prototype Pollution
| Impact | Details |
|---|---|
| Privilege Escalation | A regular user can gain Admin privileges by injecting an isAdmin value into the Prototype. |
| Bypass Authentication | Authentication checks can be bypassed if the system verifies against a polluted Property. |
| Remote Code Execution (RCE) | In some cases, it can lead to direct code execution on the server. |
| Denial of Service (DoS) | Causes the system to malfunction or crash because every Object carries incorrect values. |
How Does Prototype Pollution Occur?
This vulnerability typically arises from code that accepts external JSON and merges it into internal system Objects without filtering — for example:
A risky scenario:
- The system has an "update user profile" function that accepts JSON from the Client.
- The function merges the received data with the user's Object using a Deep Merge without filtering Keys.
- The hacker sends JSON with a special Key (
__proto__) to modify the Prototype of every Object in the system. - Every new Object created after this will carry the values set by the hacker.
How to Prevent Prototype Pollution
1. Reject Special Keys from External Input
When receiving JSON data from a Client, you must filter out dangerous Keys before every Merge — Keys that must always be rejected: __proto__, constructor, prototype
2. Use Object.create(null) Instead of Regular Objects
Create an Object that has no Prototype Chain — making it impossible to be polluted via __proto__ .
3. Use Map Instead of Plain Objects
JavaScript provides Map which is designed specifically for storing Key-Value pairs — with no Prototype Chain that can be polluted. Ideal for handling data from external sources.
4. Schema Validation
Validate incoming data with Schema Validation — define in advance which Fields the incoming JSON can contain. Fields not in the Schema are immediately rejected.
5. Audit Dependencies
Many popular libraries have had Prototype Pollution vulnerabilities, such as Lodash (the merge, defaultsDeep) and jQuery (the $.extend) — you must always update Dependencies to the latest version and use audit tools such as npm audit to perform regular checks.
How Do Enterprise ERP Systems Protect Against These Threats?
A quality ERP system implements multiple layers of protection against both XSS and Prototype Pollution vulnerabilities:
| Protection Layer | XSS Protection | Prototype Pollution Protection |
|---|---|---|
| Frontend Framework | Auto-sanitization for all Data Binding | Using Frameworks without unfiltered Deep Merge |
| API Layer | Validate Input on every Request | Schema Validation + rejecting dangerous Keys |
| HTTP Headers | Content Security Policy (CSP), X-Content-Type-Options | — |
| Session Management | HttpOnly + Secure Cookie | Token-based Auth that does not rely on Object Properties |
| Dependency Management | Updating vulnerable Libraries | Auditing Dependencies + updating Patches |
How Does Saeree ERP Protect Against XSS and Prototype Pollution?
Saeree ERP is architected with security in mind from the ground up, with the following vulnerability protection mechanisms:
Frontend — Angular with Strict Mode
Saeree ERP uses Angular which has a built-in Sanitization system that automatically prevents XSS:
- Auto-Escape for all Data Binding — All values displayed through Templates are automatically escaped. If an attacker attempts to inject HTML tags or Scripts, they will render as plain text only.
- Strict Templates — Enables strictTemplates mode that checks the data type at every Template binding point, reducing the chance of mistyped data slipping through to display.
- TypeScript Strict Mode — Enforces Type Safety across the entire project, preventing incorrectly typed data from entering the system.
Backend — Java + PreparedStatement
Saeree ERP's backend is developed with Java which offers significant security advantages:
- has no Prototype Chain — Java does not have a Prototype mechanism like JavaScript, therefore Prototype Pollution is impossible by the very nature of the language.
- PreparedStatement for every Query — All database access uses Prepared Statements with Parameter Binding at every point, providing complete SQL Injection protection.
Security Headers
Saeree ERP configures HTTP Security Headers to add additional layers of protection:
| Header | Value Set | What It Prevents |
|---|---|---|
| X-Frame-Options | DENY | Prevents Clickjacking — does not allow embedding the page in an iframe. |
| Strict-Transport-Security | max-age=31536000 | Enforces HTTPS at all times — prevents Man-in-the-Middle attacks. |
| X-Content-Type-Options | nosniff | Prevents MIME Sniffing — the browser does not guess file types on its own. |
| Referrer-Policy | no-referrer | Does not send the origin URL with Requests — prevents data leakage. |
Authentication — Apache Shiro
Saeree ERP's authentication system uses Apache Shiro which is an enterprise-grade Security Framework featuring a Permission-based Authorization — providing granular permission control down to the function level. Even if an attacker gains system access, they cannot reach unauthorized data or functions.
Saeree ERP uses technologies with built-in protection from the architectural level — Angular for XSS Protection, Java for Type Safety, PreparedStatement for SQL Injection, and Apache Shiro for Authentication. This ensures that common web application vulnerabilities are automatically prevented from the start.
— Saeree ERP Team
Summary — XSS and Prototype Pollution Prevention Checklist
| Items | XSS | Prototype Pollution |
|---|---|---|
| Encode/Escape Output before rendering | ✓ | — |
| Set Content Security Policy (CSP) | ✓ | — |
| Use a Framework that auto-sanitizes | ✓ | — |
| Set Cookies to HttpOnly + Secure | ✓ | — |
| Filter dangerous Keys (__proto__, constructor) | — | ✓ |
| Use Object.create(null) or Map | — | ✓ |
| Schema Validation for external data | ✓ | ✓ |
| Audit + update Dependencies | ✓ | ✓ |
If your organization is looking for an ERP system that prioritizes enterprise-grade security, you canschedule a demo or consult with our expert team right away.