Most business website breaches exploit well-known mistakes: permissions the server never checks, misconfigurations such as debug mode left on, outdated plugins and libraries, SQL injection, and weak passwords without two-factor authentication. Protection starts with updated components, server-side authorization checks, prepared queries, HTTPS and isolated backups. An SSL certificate alone is not enough.
What is the OWASP Top 10 and why should a site owner care?
OWASP is a non-profit that publishes a list of the most critical web application security risks, used by developers and penetration testers as a shared reference. The latest edition is the OWASP Top 10:2025. You do not need the technical details, but you should ask whoever builds your site how they handle each category:
| Code | Category | Example on a business site or store |
|---|---|---|
| A01 | Broken Access Control | A customer sees another customer's invoice by changing its number in the URL |
| A02 | Security Misconfiguration | Debug mode on the live server exposes file paths and keys |
| A03 | Software Supply Chain Failures | An outdated WordPress plugin or npm package with a published vulnerability |
| A04 | Cryptographic Failures | Passwords stored weakly, or a login page without HTTPS |
| A05 | Injection | SQL injection through the search box, or script injection in comments (XSS) |
| A06 | Insecure Design | A discount code that can be reused without limit because the system was never designed to prevent it |
| A07 | Authentication Failures | An admin panel that accepts unlimited login attempts without two-factor authentication |
| A08 | Software or Data Integrity Failures | Updates or scripts loaded from an untrusted source without verification |
| A09 | Security Logging and Alerting Failures | Suspicious login attempts continue for weeks without anyone noticing |
| A10 | Mishandling of Exceptional Conditions | An unexpected error completes an order without payment, or shows system details to the visitor |
Which vulnerabilities are most dangerous for business websites, and how do you close them?
1. Broken access control (IDOR)
This happens when the system only checks that a user is logged in, not that they own the data they request. Example: changing /api/invoices/100 to /api/invoices/101 to view another customer's invoice.
Fix: check ownership of every record on the server for every API request, for example with Laravel Policies, and never rely on hiding buttons in the interface.
2. Misconfiguration and leaked errors
APP_DEBUG left on in production, a downloadable .env file, directory listing, or default database passwords.
Fix: disable debug mode on the live server, block sensitive files and directory listing, and enable security headers: Content-Security-Policy, X-Frame-Options (to stop your site being framed by a phishing page), X-Content-Type-Options and HSTS.
3. Outdated libraries and plugins
Every plugin or package you add is code you did not write. Outdated WordPress plugins and old npm or Composer packages are a frequent entry point, because their vulnerabilities are published in CVE databases and attackers scan for them automatically.
Fix: run npm audit, composer audit or a tool such as Snyk regularly, update packages, and remove plugins you do not use.
4. SQL injection
An attacker submits malicious text in a search or login field that runs as part of a database query, letting them read, modify or delete tables.
Fix: always use prepared statements or an ORM such as Eloquent or Prisma, and never concatenate user input into query text. Connect with a database user that has the minimum privileges needed, not root.
5. Cross-site scripting (XSS)
An attacker injects JavaScript into content other people see, such as a comment or product review, to steal cookies or redirect visitors to a fake page.
Fix: encode all user output before rendering it, apply a Content-Security-Policy, and set the HttpOnly flag on session cookies.
6. Cross-site request forgery (CSRF)
An external page makes a logged-in user's browser send a request they did not intend, such as changing the account email.
Fix: a CSRF token in every form that changes data, verified by the server, plus the SameSite cookie attribute. Frameworks such as Laravel provide this by default, but the protection is lost if routes are excluded from it without a good reason.
7. Weak login and session management
Snaabble provides a tailored technical assessment to define the right stack & exact budget.
Weak passwords, unlimited login attempts, and sessions that stay valid after logout.
Fix: OWASP's Password Storage Cheat Sheet recommends Argon2id first, and bcrypt for legacy systems that already use it. Add two-factor authentication to the admin panel, rate-limit login attempts, and truly end sessions on logout or password change.
8. API abuse and paid-service exhaustion
Thousands of automated requests to an OTP endpoint or an AI feature can take the server down or burn through SMS credit and AI API budgets you pay for.
Fix: rate limits per user and per IP address (for example with Redis), a human verification challenge on public forms, and alerts when usage spikes suddenly.
9. Unvalidated file uploads
An image or CV upload form that accepts any file lets an attacker upload an executable web shell and take control of the server.
Fix: validate the file type and content on the server, not just the extension; store uploads outside the public web root or in separate storage; and prevent execution.
10. Missing logs and monitoring
Without logs of failed logins and sensitive changes, an attacker can stay inside the system unnoticed.
Fix: log security events somewhere the attacker cannot modify, alert on unusual patterns, and put a web application firewall (WAF) such as Cloudflare or AWS WAF in front of the site.
Which protection layers do you need at the server and hosting level?
| Layer | Measure | What it prevents |
|---|---|---|
| Connection encryption | HTTPS with a modern TLS version and an HSTS header | Eavesdropping on data in transit (man-in-the-middle) |
| Web application firewall (WAF) | Filtering requests before they reach the server and blocking malicious bots | Automated attack attempts and part of denial-of-service (DDoS) traffic |
| Server access | SSH keys only, closing unused ports, installing security updates | Password guessing and exploitation of forgotten services |
| Database | A limited-privilege user, and no direct access from the internet | A small bug turning into theft of all data |
| Backups | Regular encrypted backups stored off the web server, with tested restores | Data loss after a breach or ransomware |
Backup details are in our website backup strategy article. If your site takes payments, do not store card data on your server at all; leave that to the payment gateway's hosted checkout, as explained in the payment gateways guide.
Are you legally required to protect customer data in Egypt?
Yes. Egypt's Personal Data Protection Law No. 151 of 2020 regulates how personal data is collected and processed, and its executive regulations were issued in November 2025. Among their requirements, a licence or permit from the Personal Data Protection Center is needed before transferring personal data outside Egypt. A vulnerability that exposes customer data is therefore a legal liability, not just a technical problem. Review your position with a lawyer and read customer data protection and compliance.
What should you check before launching a website or web app?
- HTTPS enforced on every page, with HSTS.
- Debug mode off, and error messages that reveal no code details.
- API keys and passwords in server environment files, never in the code or the front end.
- Every API endpoint checks permissions and data ownership.
- Two-factor authentication and login rate limits on the admin panel.
- A package audit (npm audit or composer audit) with no open critical issues.
- Server-side validation of uploaded files.
- A recent off-server backup whose restore has been tested.
- Security event logs, with alerts on repeated failed logins.
What should you do if your site is hacked?
- Isolate the site or put it in maintenance mode to stop the damage.
- Copy logs and current server files before changing anything; they show how the attacker got in.
- Change all passwords, API keys and access tokens.
- Restore the latest clean backup from before the breach.
- Find and fix the exploited vulnerability before relaunching, or the breach will repeat.
- If personal data leaked, review the notification obligations under the data protection law with your lawyer.
What else do site owners ask about website security?
Is an SSL certificate enough to protect a site from hacking?
No. SSL encrypts data between the browser and the server to prevent eavesdropping, but it does not stop SQL injection, XSS, broken access control or an exploited outdated plugin.
Do frameworks like Laravel or Next.js protect against all attacks automatically?
They include useful built-in protection, such as CSRF tokens, output encoding and prepared queries through the ORM, but they do not write your authorization rules or prevent logic flaws such as a discount code with no usage limit. For a framework comparison, read when to use React and when to use Laravel.
What is penetration testing and when do you need it?
Penetration testing is a simulated attack performed by specialists with your permission to find vulnerabilities before attackers do. You need it before launching a system that handles payments or sensitive data, and after major changes to permissions or architecture.
How can I tell whether my current site has vulnerabilities?
Start with quick checks: plugin and package versions, debug mode status, security headers and admin account permissions. Then ask an independent party for a code review or penetration test of the sensitive parts.
Snaabble is a software company based in Talkha, Dakahlia, Egypt, building websites and web applications and custom business systems. To discuss the security of your site or system, contact us on WhatsApp at +20 103 673 3131 or at hello@snaabble.com. Directions are on our location page.
