Website and Web App Security: 12 Essentials Before Launch

Most security problems in business websites and web systems are not exotic hacks. They are ordinary gaps: an admin page that anyone can open if they guess the URL, a login form that allows unlimited password guesses, an old library with a known flaw, a backup that was never tested. In Egypt, the stakes rose in 2026, because the Personal Data Protection Law's regulations require companies to report personal data breaches within 72 hours.

The short answer: before launch, check twelve essentials: HTTPS, server-side access control, strong login protection, secure sessions, input validation, security headers, safe configuration and secrets, updated dependencies, safe file uploads, logging and alerting, tested backups, and abuse limits. This checklist is mapped to the OWASP Top 10:2025, the widely used list of the most critical web application security risks.

Key takeaways

• Broken access control is first in the OWASP Top 10:2025; every request must be checked on the server, not only hidden in the interface.
• Protect logins with salted password hashing, rate limiting and multi-factor authentication for admins.
• Keep session tokens out of reach of scripts with HttpOnly, Secure and SameSite cookies.
• Software supply chain failures are now a Top 10 category: track and update every library you depend on.
• Logging, alerting and tested backups decide whether a breach is a bad day or a disaster.

The OWASP Top 10:2025 in one table

OWASP (the Open Worldwide Application Security Project) publishes the Top 10 as an awareness standard. The 2025 edition lists:

Essentials 1 to 4: connection, access and login

1. HTTPS everywhere

Every page, API and admin panel should use HTTPS with a valid SSL/TLS certificate, with HTTP redirected to HTTPS and HSTS enabled so browsers refuse insecure connections. This protects logins and personal data in transit, including on public Wi-Fi in cafés and co-working spaces.

2. Access control checked on the server (A01)

Hiding a button is not security. Each request must be checked on the server: is this user logged in, does their role allow this action, and does this record belong to them? A classic flaw is changing an order number in the URL and seeing another customer's order. Test for it explicitly, especially in customer portals and clinic or HR systems.

3. Strong authentication (A07)

• Store passwords only as salted hashes with a slow algorithm such as bcrypt; see encryption with salting.
• Apply rate limiting to login, password reset and OTP endpoints so attackers cannot guess endlessly.
• Require multi-factor authentication for admin and finance accounts.
• Give generic error messages ("wrong email or password") so attackers cannot discover which accounts exist.

4. Secure sessions and tokens

Session or refresh tokens belong in HttpOnly cookies marked Secure and SameSite, where page scripts cannot read them. If you use JWT access tokens, keep them short-lived, rotate refresh tokens, store them hashed on the server, and revoke them on logout and password change.

Essentials 5 to 8: input, configuration and dependencies

5. Validate input and use parameterised queries (A05)

Validate every input on the server against a schema, for example with Zod: type, length, format and allowed values. Build database queries with parameters or a well-used ORM, never by joining strings. Escape output in pages to prevent cross-site scripting.

6. Security headers and a strict CORS policy (A02)

Tools such as Helmet set protective HTTP headers, including a content security policy that limits where scripts can load from and prevents your pages being framed by other sites. Configure a CORS policy that allows only your own domains to call your APIs.

7. Safe configuration and secrets (A02, A10)

• Keep passwords, API keys and payment gateway secrets in environment variables or a secret store, never in the code repository.
• Remove default accounts, sample pages and debug modes.
• Show users a generic error page; send technical details only to the logs.
• Make sure the system fails safely: if a payment callback errors, the order should not be marked as paid.

8. Know and update your dependencies (A03)

Modern systems depend on hundreds of open-source packages. Commit lock files, run dependency audits before each release, remove unused packages and schedule updates. For WordPress sites, the same applies to plugins and themes.

Essentials 9 to 12: uploads, logs, backups and abuse

9. Safe file uploads

Uploads such as CVs, product images or prescriptions are a common attack path. Check file type by content, not just extension, limit size, rename files, store them outside the public web folder where possible, and re-encode images with a library like Sharp to strip hidden content and metadata.

10. Logging and alerting (A09)

Log security events: logins, failed logins, permission changes, exports and admin actions, in a structured format such as Pino produces. Do not log passwords, full card numbers or unnecessary personal data. Set alerts for spikes in failed logins or unusual exports. Without logs, you cannot tell what happened in a breach, or whom to notify.

11. Backups you have actually restored

Back up the database and uploaded files automatically, keep copies in a separate location, encrypt them, and test a full restore before launch and regularly after. Ransomware and accidental deletion are recovered from backups, not apologies.

12. Limits against abuse and bots

Contact forms, sign-ups, OTP requests and search endpoints need rate limits and, where useful, bot protection. Otherwise, one script can send thousands of SMS messages on your account or fill your CRM with junk leads.

Extra points for online stores and payments

• Use the payment gateway's hosted checkout or secure fields, so card data never touches your server. Egyptian gateways such as Paymob and Fawry offer integration options for this.
• Verify payment callbacks with the gateway's signature before updating an order.
• Recalculate prices and totals on the server; never trust amounts sent from the browser.
• Protect the admin panel with multi-factor authentication and, if possible, an IP allow-list.

Why this matters under Egypt's data protection law

Law 151/2020 and its executive regulations, issued in November 2025 with a grace period ending on 1 November 2026, require appropriate security measures for personal data. According to Al Tamimi's 2025 analysis, controllers and processors must notify the Personal Data Protection Center within 72 hours of becoming aware of a breach, and inform affected individuals within three working days of that notification. Good logging and access control make that timeline achievable. Our guide on data breach notification within 72 hours covers the response plan.

Pre-launch sign-off checklist

For deeper verification, OWASP's Application Security Verification Standard (ASVS) provides detailed requirements, and an independent penetration test is worth it for systems holding payment, health or large volumes of customer data.

How Nilex helps

Nilex builds these controls into its systems from the start: Helmet security headers, rate limiting on logins and forms, HttpOnly cookies with rotating refresh tokens, salted password hashing, schema validation on every request and structured logs. If you already have a website or system, we can review it against this checklist and fix the gaps. Get in touch through our contact page.

Frequently asked questions

What is the OWASP Top 10?

It is an awareness document from OWASP listing the most critical security risks in web applications. The current edition is the OWASP Top 10:2025, led by broken access control and security misconfiguration.

Is an SSL certificate enough to make my website secure?

No. HTTPS protects data in transit, but it does not stop broken access control, weak passwords, vulnerable plugins or injection attacks. It is the first essential, not the only one.

How often should a website be security tested?

Before launch, after major changes, and on a regular schedule, with dependency updates checked monthly. Systems handling payments or health data benefit from periodic independent penetration tests.

Do small business websites really get attacked?

Yes. Automated bots scan the internet for known weaknesses, default passwords and outdated plugins regardless of company size. Small sites are often easier targets.

What should I do first if I suspect a breach?

Contain it, preserve logs, involve your technical team and data protection officer, and assess whether personal data was affected, because the 72-hour notification clock under Egypt's regulations may apply.

Launching a new website, store or system, or unsure about an existing one? Ask us for a security review against these twelve essentials through our contact page.