- 20
- February
SQL Injection is a security vulnerability consistently ranked as #1 in the OWASP Top 10 — an attack where malicious actors inject SQL commands through application input fields to access, modify, or delete database records without authorization. This article explains why SQL Injection is dangerous and why ORM (Object-Relational Mapping) and Parameterized Query are the best defenses — including the architectural design principles Saeree ERP uses to prevent this vulnerability from the ground up.
What Is SQL Injection?
SQL Injection is a technique where attackers inject SQL commands into user input fields (such as login forms and search boxes) to make the system execute unintended SQL commands.
What Causes the Problem?
The root cause is developers directly concatenating user input with SQL commands — allowing attackers to "trick" the system into treating submitted data as part of the SQL command rather than plain data.
Attack Principle (simplified):
The attacker enters specially crafted data in the login or search field that makes the SQL condition always evaluate to true — gaining system access without a password, or extracting, modifying, or deleting all database records.
Potential Damage
| Attack Type | Impact |
|---|---|
| Bypass Authentication | Gain system access without knowing the password |
| Data Exfiltration | Extract all user data, financial data, and customer data |
| Data Destruction | Delete tables or modify data across the entire database |
| Privilege Escalation | Escalate a regular user to admin privileges |
Why Are ERP Systems a Prime Target?
ERP systems store an organization's most critical data:
- Financial data — revenue, expenses, balance sheets, bank accounts
- Personnel data — salaries, national ID numbers, bank account numbers
- Customer data — addresses, tax IDs, purchase orders
- Inventory data — cost prices, quantities, suppliers
If an ERP system has a SQL Injection vulnerability, attackers can access all of this data — and the organization also risks violating the Personal Data Protection Act (PDPA).
How to Prevent SQL Injection
There are 2 main industry-standard approaches:
Approach 1: Parameterized Query (Prepared Statement)
Instead of directly concatenating strings into SQL — use placeholders ? and pass values separately:
Principle:
Instead of writing WHERE name = '(user value)' directly
Write WHERE name = ? and bind the value separately
The database driver separates the "SQL structure" from the "data values" — even if an attacker sends malicious data, the system treats it as plain text, not as SQL commands.
Approach 2: ORM (Object-Relational Mapping)
ORM is a layer between code and the database — developers work with objects instead of writing raw SQL. For example, to create new data: create an object, set values, call save, and the framework automatically generates a parameterized INSERT statement.
ORM prevents SQL Injection because:
- No hand-written SQL — the framework generates SQL automatically
- Uses Parameterized Query internally — all values are bound separately from SQL
- Type-safe — int variables must be int, String must be String, preventing type-mismatch exploits
How Saeree ERP Prevents SQL Injection
Saeree ERP's entire architecture is designed to never concatenate user input directly into SQL strings at the framework level, using these principles:
1. ORM Pattern for All Write Operations
All INSERT, UPDATE, and DELETE operations in Saeree ERP use ORM (Object-Relational Mapping) — developers work with objects without writing any SQL. The framework automatically generates parameterized SQL statements.
Conceptual Example: Creating Data in the System
Saeree ERP's Approach:
- Create objects for business entities (e.g., vendors, employees, purchase orders)
- Set values via setter methods (e.g.,
setName(),setTaxID()) - Call
save()→ Framework auto-generates parameterized INSERT/UPDATE - Everything runs within a transaction — errors trigger a full rollback
Conceptual Example: Registering a New Employee
Process:
- Open a transaction
- Create a person data object → set first name, last name, ID number → save
- Create an HR data object → link to person data → save
- Create a user account object → set email → save
- Commit transaction — all 3 records succeed together or are all rolled back
Not a single SQL statement in the code — the ORM framework handles everything.
2. Parameterized Query for All Read Operations
For data retrieval (SELECT) that requires writing SQL — Saeree ERP uses Prepared Statement + Placeholder ? at every point. User values are always bound separately and never concatenated directly into SQL strings.
Principle:
- SQL uses
?as a placeholder wherever user values appear - Actual values are bound via
setInt(),setString(),setTimestamp()separately - Even dynamic searches (multiple conditions) only add
?placeholders — values are never concatenated into SQL
3. Clear Layered Architecture
Saeree ERP's architecture is divided into 3 distinct layers:
| Layer | Responsibility | Contains SQL? |
|---|---|---|
| API Layer | Sends/receives data with client (REST API) | No SQL |
| Service Layer | Processes business logic | ORM + Parameterized Query only |
| Data Model | Transfers data between layers (DTO) | No SQL — pure data objects |
This layered separation ensures that user data never directly touches SQL — everything must go through ORM or Parameterized Query.
Summary of Saeree ERP's SQL Injection Prevention
| Operation | Method Used | SQL Injection Risk |
|---|---|---|
| INSERT (Create) | ORM Object → save | None — Framework generates parameterized SQL |
| UPDATE (Modify) | ORM Object → save | None — Framework generates parameterized SQL |
| DELETE (Remove) | ORM Object → delete | None — Framework generates parameterized SQL |
| SELECT (Search) | Parameterized Query + Placeholder | None — values bound separately from SQL |
| Login (Authentication) | Parameterized Query + Security Framework | None — all parameters are bound |
Comparison: Vulnerable Code vs Saeree ERP Code
| Vulnerable Code | Saeree ERP Code |
|---|---|
| Concatenates user values directly into SQL | Uses placeholders with separately bound values |
| Writes INSERT/UPDATE SQL manually | Uses ORM objects — framework generates SQL |
| SQL and data in the same string | SQL and data 100% separated |
| Depends on individual developers | Framework enforces safety by design |
SQL Injection is 100% preventable when designed correctly from the start — Saeree ERP uses ORM for all write operations and Parameterized Query for all read operations, ensuring user data can never become SQL commands.
- Saeree ERP Development Team
Checklist for Organizations — Is Your System Safe from SQL Injection?
| ☐ | Do all SQL queries use Parameterized Query / Prepared Statement? |
| ☐ | Is there no direct string concatenation of user input into SQL? |
| ☐ | Does the system use ORM or a framework that handles SQL automatically? |
| ☐ | Does the application's database user have only the necessary privileges (Least Privilege)? |
| ☐ | Is input validation performed before data enters the system? |
| ☐ | Do error messages avoid exposing SQL errors or database structure to users? |
| ☐ | Are regular SQL Injection audits / code reviews conducted? |
If your organization is looking for an ERP system that prioritizes security from the architectural design level, you can schedule a demo or contact our consulting team to learn more.
