The Attack That Nobody Sees Coming
In March 2025, a mid-sized e-commerce business based in Pune discovered that its customer database had been accessed and exfiltrated over a period of eleven months. The breach exposed the names, phone numbers, email addresses, and purchase histories of over 180,000 customers. The attack method was not sophisticated. It was a basic SQL injection vulnerability in a contact form that a freelancer had built three years earlier using an outdated PHP library. The form had never been updated. The vulnerability had been publicly documented for two years. An automated scanning tool found it in minutes, and a script running on a rented server in Eastern Europe quietly extracted the entire database over the following months while the business's team focused on marketing, operations, and growth — completely unaware that every customer record they had ever collected was being copied and sold.
This story is not exceptional. It is representative of a pattern that plays out thousands of times every year across Indian businesses of every size and sector. The Indian Computer Emergency Response Team reported over 1.3 million cybersecurity incidents in India in 2023 alone, a number that has grown every year since. The average cost of a data breach for an Indian organisation reached 19.5 crore rupees in 2024, according to IBM's Cost of a Data Breach Report — and that figure covers only the direct costs of investigation, notification, and remediation, not the longer-term costs of reputation damage, customer loss, and regulatory penalties that follow a public breach. For small and mid-sized businesses, a breach of that magnitude is not a setback. It is an existential event.
Why Indian Business Websites Are Disproportionately Vulnerable
The vulnerability gap in Indian business websites is not a reflection of a lack of awareness among business owners — most business owners understand abstractly that cybersecurity matters. It is a structural consequence of how most Indian websites are built and maintained. The dominant model for business website development in India involves a freelancer or small agency building a WordPress site on a template, deploying it to cheap shared hosting, handing over the credentials, and moving on to the next project. The business owner receives a website that looks professional, functions adequately for its initial purpose, and contains a security architecture that was never explicitly designed — it simply inherited whatever default settings came with the theme, the plugins, and the hosting plan.
WordPress powers approximately 43% of all websites globally, which makes it the single most targeted platform for automated attacks. Attackers do not manually probe WordPress sites one at a time. They run automated bots that scan millions of URLs simultaneously, testing for known vulnerabilities in specific plugin versions, theme files, and core installations. When a vulnerability is discovered in a popular plugin — which happens multiple times every month — automated tools begin exploiting it within hours of the public disclosure. A WordPress site whose plugins have not been updated in six months almost certainly contains at least one publicly documented vulnerability that automated tools are already probing for. Most Indian business websites are not updated on any regular schedule, because the developer who built them is no longer engaged on a retainer and the business owner does not know that updates are a security responsibility, not just a feature improvement.
The Six Attack Vectors That Compromise Most Business Websites
Understanding how attacks actually happen is more useful than a general warning that attacks exist. The following six attack methods account for the overwhelming majority of successful compromises against business websites in India, and each one has a specific, implementable defence that any competent development team should be building into every project by default.
SQL Injection remains the most common web application attack method globally despite being one of the oldest known vulnerabilities. It works by inserting database commands into form fields — search boxes, contact forms, login fields, registration forms — that were built without properly validating and sanitising the input they receive. When a form accepts whatever a user types and passes it directly to the database, an attacker can type a database command instead of a name or email address, and the database executes it. The consequences range from data extraction to complete database deletion. The defence is rigorous input validation on every form field, on both the client side and the server side independently, using schema validation that rejects any input that does not conform to the expected format before it ever reaches the database layer. Every form field on every page is a potential entry point, and every one of them must be treated as hostile input by default.
Brute force attacks on login pages are exactly what they sound like — automated tools attempting thousands of username and password combinations per minute against your login endpoint until they find credentials that work. A WordPress admin login page with no rate limiting, no account lockout, and no multi-factor authentication is an open invitation for this attack method. The defence is rate limiting — a system that tracks how many login attempts have been made from a given IP address in a given time window and blocks further attempts once a threshold is crossed. Redis-based rate limiting can enforce rules like maximum five login attempts per IP per minute with a one-hour block on breach at the infrastructure level, making brute force attacks computationally and economically impractical. Without it, the only thing standing between an attacker and your admin panel is the quality of your password.
Exposed API endpoints are an increasingly critical vulnerability as more business websites include dynamic functionality — contact forms that write to databases, admin panels that read and write customer data, booking systems that process payments, and content management systems that modify live site content. Every one of these functions is powered by an API endpoint — a URL that accepts a request and performs an action. If those endpoints are not protected by authentication that verifies the identity and permissions of every request, they are accessible to anyone who discovers their URL. Attackers enumerate API endpoints systematically, testing for endpoints that perform sensitive operations — deleting records, accessing user data, modifying content — without verifying that the requesting party has the right to perform that action. An unprotected admin API endpoint can allow a completely unauthenticated attacker to delete your entire database, extract all customer records, or modify your site's content, simply by sending the right HTTP request to the right URL.
Cross-site scripting, known as XSS, allows attackers to inject malicious JavaScript code into pages that other users will view. This typically happens through user-generated content — comments, reviews, profile fields, search queries — that is displayed on the site without sanitisation. When a visitor loads a page containing injected JavaScript, that script runs in their browser with full access to their session cookies, their form inputs, and their interactions with the page. Attackers use XSS to steal session tokens and impersonate logged-in users, redirect visitors to phishing pages, and silently harvest credentials as they are typed. The defence is HTML sanitisation — stripping or encoding all HTML and JavaScript from any content that originates from user input before it is stored or displayed.
Insecure file uploads affect any website that allows users to upload files — job application portals accepting resumes, real estate sites accepting property photos, healthcare platforms accepting documents, e-commerce sites accepting product images. Without proper validation, an attacker can upload a PHP script disguised as an image file. If that file is stored in a web-accessible directory and the server is configured to execute PHP files, the attacker has installed a backdoor that gives them the ability to execute arbitrary commands on your server, access your file system, read your environment variables and database credentials, and use your server as a launchpad for attacks against other systems. The defence involves validating file type against actual file content rather than the extension the uploader provided, storing uploaded files in non-executable directories or external storage services, and using a cloud storage provider like Cloudinary that handles file processing in an isolated environment completely separate from your application server.
Leaked credentials in source code is a vulnerability that developers create unintentionally and that causes breaches that are completely avoidable. Database connection strings, API keys, payment gateway credentials, email service passwords, and cloud storage secrets are supposed to be stored in environment variables — configuration values that exist on the server but never appear in the codebase. When developers hardcode these values directly into source files and those files are committed to a version control repository — especially a public one on GitHub — automated tools that scan public repositories for credential patterns find them within minutes. In 2024, the GitHub Secret Scanning service blocked over 35 million exposed secrets from reaching public repositories. The ones it did not catch are actively exploited. A leaked database credential gives an attacker direct access to your production database with no need to exploit any application vulnerability at all.
What a Properly Secured Website Actually Looks Like in 2026
The security measures described above are not advanced, specialised, or expensive additions to a web development project. They are the baseline standard that any competent development team should implement on every project, for every client, without needing to be asked. The fact that most Indian business websites lack them is not evidence that they are difficult to implement. It is evidence that the teams that built those websites did not prioritise them, did not know to prioritise them, or were working under budget and timeline constraints that caused security to be treated as optional.
A properly secured web application in 2026 validates and sanitises every piece of user input on both client and server independently, treating every form field as potentially hostile regardless of what the client-side validation already checked. It protects every API endpoint with authentication middleware that verifies a valid, unexpired cryptographic token before executing any action, and enforces role-based permissions so that authenticated users can only access the resources their role permits. It implements rate limiting on every public-facing endpoint — login, registration, contact, search, booking — using a fast in-memory store like Redis that can enforce limits at hundreds of requests per second without adding meaningful latency to legitimate requests. It stores all secrets in environment variables that never appear in source code. It uses a cloud storage provider for all user-uploaded files, so that no uploaded content ever reaches the application server's file system. It sanitises all user-generated content before storage and again before display. It enforces HTTPS on every request and sets security headers — Content Security Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security — that defend against a range of client-side attack vectors at the browser level.
Beyond the application layer, a properly secured deployment uses containerisation — Docker — to isolate the application from the host server, limiting the blast radius of any compromise. A reverse proxy like Nginx sits in front of the application, terminating SSL, enforcing connection limits, and filtering malformed requests before they ever reach application code. Monitoring and alerting systems watch for anomalous patterns — unusual volumes of failed login attempts, unexpected spikes in API calls to sensitive endpoints, database queries that look structurally different from normal application traffic — and alert the development team before a breach progresses from probe to exfiltration.
The Questions Every Business Owner Must Ask Before Trusting an Agency With Their Platform
Most business owners are not developers, and they should not need to be in order to make an informed decision about whether the team they are hiring is building their platform securely. The following questions require no technical knowledge to ask, and they will tell you a great deal about whether a development agency takes security seriously or treats it as someone else's responsibility.
Ask them how they handle user input validation. A team that builds securely will immediately describe client-side and server-side validation, schema validation libraries, and the principle of never trusting user input. A team that does not prioritise security will describe their validation approach vaguely or say they use the validation that comes with their framework by default. Ask them how they protect admin and API routes from unauthorised access. A team with a real security posture will describe authentication middleware, JWT verification, role-based access control, and the specific points in the request lifecycle where authorisation is enforced. Ask them how they protect your login page from brute force attacks. A team that has thought about this will describe rate limiting, account lockout policies, and optionally multi-factor authentication. Ask them where your uploaded files are stored and how they are validated. A team with secure file handling will describe cloud storage, content-type validation, and the isolation of uploaded files from the application server. Ask them how secrets and credentials are managed. A team with secure development practices will describe environment variables, secret management, and a policy against hardcoding credentials. If any of these questions produce a vague, dismissive, or confused response, treat that as a significant signal about the security posture of everything that team builds.
How Security Is Built Into Everything Himalya NextGen Technologies Delivers
At Himalya NextGen Technologies, security is not a checklist we run through at the end of a project. It is an architectural requirement that shapes every decision from the first line of code. Every form in every application we build uses Zod schema validation on both client and server independently, with a custom sanitisation layer that strips HTML, detects SQL injection patterns, and enforces length and format constraints before any input reaches the database. Every API route in every admin panel is protected by authentication middleware that verifies a cryptographically signed JWT on every request, enforces role-based permissions, and returns a generic error response that reveals no internal system information to unauthenticated callers. Every public endpoint — contact forms, booking requests, job applications, newsletter subscriptions — is protected by Redis-powered rate limiting that prevents automated abuse without affecting legitimate users.
All user-uploaded files, including PDFs, images, and documents, are routed through Cloudinary, which processes them in an isolated environment, validates their actual content type independently of the extension provided, and stores them on a CDN completely separate from our application servers. No uploaded content ever touches the server running the application. All credentials, API keys, and secrets are stored in environment variables and are never present in source code or version control. Our deployments run in Docker containers behind an Nginx reverse proxy with full HTTPS enforcement, security headers, and connection rate limiting at the network level. Every project includes Sentry error monitoring configured to capture application errors without exposing stack traces or internal system information to end users.
This is the standard we build to for every client, on every project, regardless of size or budget — because the cost of building securely from the beginning is always lower than the cost of recovering from a breach that a proper architecture would have prevented entirely. If you are evaluating development partners for a new project, or if you have an existing website you suspect may not meet the security standard your business and your customers deserve, we would welcome the conversation. A security review of an existing system is often the most valuable engagement a business can have before something goes wrong rather than after.