Website security in Uzbekistan: defending against DDoS and breaches
Most local breaches are not targeted attacks but automated scanners finding an unpatched CMS. Defence starts with hygiene, not expensive products.
What you are actually defending against
Mass vulnerability scanning: botnets sweep the internet trying exploits against popular CMSs and plugins. It is background noise that hits everyone regardless of business size.
Password brute-forcing against admin and hosting panels, SQL injection and XSS in hand-written forms, and executable uploads through an unprotected document form — four scenarios covering most incidents.
Targeted DDoS tends to arrive seasonally: before a big sale, during a tender, at peak season for delivery services. Volumetric L3/L4 attacks flood the pipe, while L7 attacks mimic real users and are more dangerous to the application.
The basic perimeter that closes most risk
HTTPS everywhere with a 301 from http, an HSTS header and automatic certificate renewal. Mixed http content inside a secure page nullifies the certificate's purpose.
Updating CMS core, plugins and dependencies is not cosmetic — it is the main security work. Set a policy: check updates fortnightly and apply critical patches immediately.
Two-factor authentication on the admin panel, hosting account and domain registrar. Restrict admin access by IP where feasible and move it off a predictable URL.
CDN and WAF as the first line
A proxying CDN such as Cloudflare solves three problems at once: it hides the origin IP, absorbs volumetric attacks upstream, and serves static assets closer to users. Locally it is also a noticeable speed win.
After enabling the CDN, firewall the origin so ports 80 and 443 accept traffic only from CDN ranges. Otherwise an attacker who finds the old IP in DNS history bypasses the protection entirely.
A WAF with managed rules blocks common injections and scanners. Add rate limiting on sensitive endpoints: login, password reset, lead submission and catalogue search.
Protecting forms and APIs
Validation must be server-side; client-side validation is a convenience only. All database access through parameterised statements, never string concatenation with user input.
Rate limits by IP and by phone number, a hidden honeypot field and a form-fill timing check stop bots better than a CAPTCHA without obstructing humans. Bring in a CAPTCHA only on suspicious behaviour.
Restrict uploads by extension and real content type, store files outside the web root and serve them through a handler. Checking extension alone is the classic hole through which web shells arrive.
Data, access and local context
Store customer personal data — phone numbers, addresses, order history — at the minimum necessary volume with sensitive fields encrypted. Data residency for citizens' data carries regulatory weight, so decide where the database lives before launch, not after.
Card data should never touch your server: payment through Payme, Click or Uzum happens on the gateway side and you receive only a token and status. Any home-made card form is a risk that never pays off.
Separate permissions: developer, content manager and owner need different roles. Maintain an explicit list of who has access to hosting, domain, database and the payment dashboard — it saves hours when an employee leaves.
Backups and incident response
Backups must be daily, automatic, stored off the server and regularly verified by restoring them. An unverified backup is not a backup but a hope, and you learn which at the worst moment.
On discovering a breach: put the site into maintenance mode, rotate every password and API key, find the entry point in the logs, restore a clean copy, close the vulnerability, and only then bring the site back. Restoring without patching gets you re-breached within a day.
Afterwards, check the search index for injected pages and the site's status in Search Console — spam pages outlive the vulnerability itself. A basic security audit on the local market runs roughly 3,000,000 – 10,000,000 UZS.