In 2023, customer data from a major Thai insurance company leaked to the dark web — over 160 million records. The resulting legal costs, reputational damage, and customer churn far exceeded what proper security investment would have cost.
Many SMEs think "we're too small for hackers to care." The reality is the opposite — SMEs are "easier targets" precisely because they typically have weaker security.
OWASP Top 10 — The Most Common Vulnerabilities
OWASP (Open Web Application Security Project) publishes the 10 most dangerous web application vulnerabilities every software house must know:
1. Broken Access Control
Regular users can access others' data or perform actions they shouldn't.
Example: Changing /profile/123 to /profile/456 in the URL to see someone else's data.
Prevention: Verify permissions on every request, not just at login.
2. Cryptographic Failures
Storing or transmitting sensitive data without encryption.
Examples: Storing passwords as plain text in a database; sending credit card data over HTTP.
Prevention: bcrypt/argon2 for passwords, TLS for every transmission, AES for sensitive data at rest.
3. Injection (SQL, NoSQL, Command)
Attackers embed code in user input, causing the database or server to run unintended commands.
SQL injection example: entering '; DROP TABLE users; -- in a username field.
Prevention: Parameterized queries, quality ORM, input validation at every entry point.
4. Cross-Site Scripting (XSS)
Attackers inject JavaScript into a page, running code in other users' browsers.
Example: Posting <script>alert('hacked')</script> in a comment field that executes for every reader.
Prevention: Output encoding, Content Security Policy (CSP) headers.
5. Insecure Design
Architecture not designed with security from the start.
Example: No rate limiting on login, enabling easy brute-force attacks.
Prevention: Threat modeling during design phase, security review before building.
Baseline Security Every Software Must Have
Authentication and Authorization
| ❌ Don't | ✅ Do |
|---|---|
| No password policy | Require 8+ characters, uppercase + numbers |
| No rate limiting on login | Lock after 5 failed attempts |
| Sessions don't expire | Auto logout after inactivity |
| No 2FA for admin | Require 2FA for all admin accounts |
Data Protection
- HTTPS everywhere — no exceptions, including internal tools
- Encrypt sensitive data at rest — personal information, financial data
- Principle of least privilege — users see and can do only what's necessary
- Data retention policy — delete data no longer needed; don't store forever
Input Validation
Validate all input on both the frontend (UX) and backend (security):
- Correct data type
- Length doesn't exceed limits
- No dangerous special characters
- No embedded scripts or SQL code
Audit Logging
Record every significant activity:
- Login/logout (successful and failed)
- Access to sensitive data
- Configuration changes
- All admin actions
Logs must be retained long enough for forensic investigation (at least 90 days).
PDPA and Your Software
Thailand's Personal Data Protection Act (PDPA) affects any software storing data about Thai individuals:
| Requirement | Software Impact |
|---|---|
| Require consent | Must have a consent management system |
| Right to access | Users can request to view their data |
| Right to erasure | Must delete data upon request |
| Breach notification within 72 hours | Must have an incident response plan |
| Data minimization | Collect only what is genuinely necessary |
Pre-Go-Live Security Checklist
- HTTPS on every endpoint
- Authentication has rate limiting
- Passwords hashed with bcrypt/argon2
- SQL/injection prevention on all inputs
- Correct session management (expiry, secure cookies)
- Access control on every API endpoint
- Sensitive data encrypted at rest
- Restrictive CORS policy
- Security headers (CSP, HSTS, X-Frame-Options)
- Dependency vulnerability scan passed
- Error messages don't expose system information
- Audit logging for sensitive operations
Summary
Security isn't optional — it's a responsibility to your customers, to the law, and to the business you've built.
The cost comparison:
- Invest in security from the start → manageable cost
- Fix after a breach → massive cost + irreparable reputational damage
A good software house integrates security from the design phase — it's never bolted on afterward.
Need a security review for software under development or already live? Contact the Adowbig team