NGO Website Development in India: Keeping a Donation Website Secure on Hosting, HTTPS, Updates, Backups and Access Control

NGO Website Development in India: Keeping a Donation Website Secure on Hosting, HTTPS, Updates, Backups and Access Control

A secure donation website for a small NGO rests on a handful of dull, repeatable habits rather than expensive tools: let a hosted payment page handle card details, keep HTTPS and updates current, give each person their own login with two-step verification and the lowest role that does the job, keep tested backups somewhere your hosting account cannot delete, and make sure the trustees, not a former volunteer or developer, own the domain and hosting accounts. Good NGO website development in India builds these habits in from the start; if your site is already live, you can retrofit most of them in a few weeks.

This article is for trustees, executive directors and volunteers who run a WordPress or custom donation site without an in-house technical team. It does not cover payment fees, tax or shipping. Technical claims come from official documentation (WordPress.org, OWASP, Cloudflare, Let's Encrypt and the CERT-In Directions) read in October 2026; where a point rests on secondary sources, such as nonprofit-sector blogs on card-testing, we say so. Prices and plan limits change, so check current pages.

The threat picture for a small NGO site

Most attacks on small sites are automated: scripts probe thousands of sites for old plugins, weak passwords and open forms, whoever owns them. Four patterns matter for a donation site.

Defacement and spam injection. An attacker in your admin, or via an outdated plugin, may change your homepage or quietly inject spam links that surface later as Google warnings.

Account takeover. A reused or weak password on the WordPress admin, the hosting panel, the domain registrar or the email account that receives password resets gives an attacker the keys. (OWASP cites a Microsoft estimate that MFA would have stopped 99.9% of account compromises; treat it as an estimate.)

Card-skimming, which a hosted checkout largely removes. Skimmers inject JavaScript into pages where people type card numbers. If your site collects card details itself, the site is the target. If your donation button sends the donor to a payment page run by a regulated payment provider, or embeds that provider's hosted fields, card numbers never touch your server. OWASP warns that third-party scripts run with full browser privileges and can be changed by the vendor without your approval. The lesson for an NGO is to keep the number of scripts on donation pages small and to avoid collecting card data on your own pages at all. If you are choosing how donations are taken, our checkout system service page describes how we approach it.

Spam donations and card-testing on donation forms. This one is specific to charities. Sector blogs from nonprofit software vendors (for example Neon One and iDonate, which we saw in search results but treat as secondary sources) describe attackers using stolen card numbers to make many small donations to see which cards still work. They say donation forms are attractive because they ask for less information than a shop checkout. The symptoms are bursts of tiny or failed donations from similar emails or one IP range. The defences are rate limiting, a bot-detection challenge verified on the server, monitoring and, where it suits your donors, a sensible minimum amount. We cover form-level bot controls in our guide to contact-form spam protection, and the same layers apply to donation forms.

Hosting tiers: what you actually get at each level

Hosting decides how much of the security burden is yours. The tiers below are generic descriptions, not vendor recommendations.

Shared hosting

Cheapest, and often enough for a brochure site with a hosted donation button. Risks: limited isolation from neighbouring sites, limited server control and short log retention. Ask the host about isolation and where backups are stored.

Managed WordPress hosting

Specialist hosts typically handle server updates and bundle staging, backups and a firewall; you still manage plugins, users and content. Check whether backups sit in the same account that could be compromised.

VPS or cloud server

Full control and full responsibility for patches, firewall and monitoring. It suits custom platforms with a technical partner on retainer, not volunteer-run sites.

Budget: we do not publish hosting prices because plans change often. TODO: confirm current rupee ranges for each tier from named hosts before quoting any figure.

HTTPS and HSTS: the basics done properly

HTTPS encrypts traffic between donors and your site and shows visitors that the connection is to the site they think it is. OWASP's Transport Layer Security Cheat Sheet recommends enforcing TLS across all pages, not only the donation page, marking cookies with the Secure flag and using HTTP Strict Transport Security (HSTS). Most current hosts already disable old TLS versions; you can check with a free tester such as SSL Labs, which OWASP lists.

Certificates

Let's Encrypt certificates are free and, per its FAQ, valid for 90 days by default, with renewal recommended every 60 days. That is why renewal must be automatic, and why someone should know where to look if it fails. ### HSTS: powerful, and easy to get wrong

HSTS tells browsers to use HTTPS only. Cloudflare's documentation explains the settings: a max-age that controls how long browsers remember the rule, an include-subdomains option, and a preload option that requires a minimum 12-month max-age. It also warns that if you later disable HTTPS, pause Cloudflare or change DNS from proxied to DNS-only after enabling HSTS, the site can become inaccessible until the max-age lapses. Subdomains without HTTPS also become unreachable if you include them.

Practical advice: confirm every page and script loads over HTTPS, enable HSTS with a short max-age, test, then lengthen it, and skip preload unless your developer understands it is hard to reverse. Planning a move? Read our donation site migration guide first.

Update discipline: the cheapest security control you have

The WordPress hardening documentation is blunt: keep WordPress up to date, since older versions lack security patches, and automatic updates have been available since WordPress 3.7. Plugins and themes are where most real-world problems arise, because each one is extra code written by a different party.

A workable routine for a volunteer-run site:

• Name one person responsible, with a named deputy.
• Take a backup before updating, as the WordPress backup documentation advises.
• Apply security updates quickly, within days rather than months. Let minor core releases update automatically if your host supports it.
• Turn off the dashboard file editor. The hardening guide recommends adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php so that an attacker with a logged-in session cannot edit theme and plugin code from the dashboard.

For custom-coded sites, someone must also watch dependency security notices. Our WordPress security checklist goes deeper on plugin choice.

Two-step verification and least-privilege roles

Two-step verification (2FA)

WordPress's developer handbook recommends two-step authentication and lists plugins including Two-Factor, Duo, Rublon and Wordfence as options. It candidly notes the trade-off: extra steps annoy some people, and lost phones lock people out, so plan for recovery.

OWASP's cheat sheet adds useful detail. SMS codes are weaker because of SIM-swap and interception risks, and NIST discourages them for sensitive applications. Authenticator apps are better; hardware keys and passkeys (FIDO2/WebAuthn) are the strongest. Email-based verification only helps if the email account itself has 2FA. Recovery is a risk too: issue single-use recovery codes at setup and store them in the organisation's password manager, not in a volunteer's personal notes.

Where to enable 2FA, in order of importance:

1. Email accounts that receive password resets.
2. The domain registrar.
3. Hosting, CDN and firewall accounts.
4. WordPress administrators and editors.
5. The payment provider dashboard.

Least-privilege roles

WordPress ships with Administrator, Editor, Author, Contributor and Subscriber roles (plus Super Admin on multisite), documented on the Roles and Capabilities page. The principle is to give each person the lowest role that lets them do their job. A volunteer who posts event updates needs Author or Editor, not Administrator. Administrators can install plugins and add users; one compromised administrator account can take over the entire site.

Practical rules:

• Keep administrators to two or three people, one of whom is a trustee or the executive director.
• One person, one account. No shared logins; they make it impossible to know who did what or to remove one person cleanly.
• Avoid obvious usernames such as "admin"; the WordPress hardening guide specifically recommends against defaults like admin or webmaster.
• Use a password manager with an organisational vault, so the credentials belong to the NGO and not to a phone.

Who holds the keys: domain, hosting and payment accounts

Many of the worst NGO website problems are ownership problems, not hacks: the domain was registered in a founder's relative's personal email, hosting is billed to a developer who stopped replying, or the payment account is in a former volunteer's name.

Set these ownership rules for each critical account:

Check today: registrant details at your registrar show the NGO and a monitored email; ask about a transfer lock; auto-renewal is on and reminders go to a shared mailbox; your developer is a collaborator, not the owner; credentials sit in the organisation's password manager with a sealed trustee copy.

Backups and a restore test (3-2-1)

A backup you have never restored is a hope, not a backup. We cover this topic in detail in our website backup and disaster recovery guide, so here is only the NGO-specific summary.

The 3-2-1 rule: three copies of your data, on two types of storage, one offsite. The WordPress backup documentation supports the spirit: keep several recent backups in different places, back up database and files, back up before every upgrade, weekly for small sites and daily for busy ones, and make an occasional manual backup to check the automated ones work.

For a donation site, "busy" is about donations, not visitors. If you receive donations every day, daily database backups are sensible. Points that matter more for an NGO:

• Keep one copy outside the hosting account. If an attacker or a billing lapse takes the account, backups stored only inside it vanish with it.
• Protect backup copies. They contain donor data, so they need access control and, ideally, encryption. See the next section on what you should be holding in the first place.
• Restore test at least twice a year. Restore to a staging site or a temporary folder, load the pages, submit a test donation in the provider's test mode and write down how long it took.

Firewall and rate limiting on donation forms

A web application firewall (WAF) filters malicious requests before they reach your site. Cloudflare says managed rules are on all plans, with the Free Managed Ruleset everywhere and the broader Managed and OWASP Core rulesets on Pro and above. Hosts and WordPress security plugins offer firewalls too; have one layer in front of the site.

Rate limiting caps how often one client can hit a URL. On Cloudflare's Free plan the documentation currently lists path matching only and one rule, so use it where it counts: the donation or payment-creation endpoint.

For a donation form specifically, combine:

1. A bot challenge verified on your server, such as Cloudflare Turnstile, reCAPTCHA or hCaptcha. A widget with no server-side check does not protect anything; see our spam-protection guide for how to verify tokens.
2. Rate limits per IP and per time window on the donation endpoint and any "create payment" API call.
3. A hosted payment page so card details never reach your server, which also reduces your exposure if the form is abused.
4. Monitoring in your payment provider's dashboard, where card-testing shows first as clusters of small failed attempts; know who receives the alerts.
5. A sensible minimum amount, if it suits your donor base. Nonprofit-sector blogs suggest minimums as a deterrent, but a high minimum can exclude small donors, so decide this deliberately.

Caution: donors on one office or mobile network can share an IP, so start conservative, review what is blocked, and avoid blocking verified search bots, which Cloudflare notes can affect SEO.

Logging: enough to investigate, not so much that it becomes a liability

When something goes wrong, logs answer what happened, when and from where. OWASP's Logging Cheat Sheet lists events to record: authentication successes and failures, authorisation failures, input validation failures, application errors and administrative actions. It also says never to log data unless it is legally sanctioned and lists things to keep out of logs entirely, including passwords, session tokens, payment card data and encryption keys. It treats logs as assets that contain personal data and must be access-controlled.

What this means on an NGO site:

• Turn on login and admin-action logging with an activity-log plugin or host audit tools.
• Check how long your host keeps access logs. Many budget plans keep them for days. Our CERT-In post describes the 180-day requirement; confirm applicability with your adviser, then decide whether to buy longer retention or export logs monthly.
• Do not log full donation forms or anything with card details.
• Limit who can read logs, because IP addresses and emails inside them are personal data.

Donor data minimisation

The less donor data you hold, the less there is to lose. This is the single most effective security measure that costs nothing.

Ask of each donation-form field: do we need it to process the gift, issue a receipt or meet a legal duty? If it is merely nice to have, drop it or make it optional. Keep donor exports out of email inboxes and personal laptops, and delete old spreadsheets.

India's Digital Personal Data Protection Act, 2023 puts duties on organisations that handle personal data, and our guide to NGO donor data protection under the DPDP Act explains notice, purpose limitation, retention and breach duties for charities. Dates and exact obligations depend on the Rules as notified, so verify them with the official text and your legal adviser rather than rely on a blog summary, ours included. Security and data protection overlap heavily: a clear retention schedule and tight access control help with both.

An incident plan you can run at 9 p.m.

Assume that at some point a volunteer will message: "Our homepage looks strange" or "Donations stopped coming through". An incident plan is a one-page document answering who does what first. Keep it printed and in the shared vault.

Within the first hour

1. Record the time and what was noticed. Take screenshots. Do not delete anything yet.
2. Notify the named incident lead (a trustee or ED) and the developer or host.
3. Contain: change passwords for hosting, WordPress admins and email from a clean device, enable maintenance mode if needed, and ask your payment provider whether to pause the donation form.
4. Preserve logs and take a snapshot of the site before cleaning it.

Next, within hours
5. Decide whether it is reportable. CERT-In's Directions set a six-hour window from awareness for listed incident types (in our earlier summary: unauthorised access, defacement, malware, DNS tampering, data breaches) and ask for a designated point of contact. Confirm applicability with a legal adviser; if donor data may be exposed, consider DPDP duties too.
6. Restore from a known-good backup if the site is compromised, then change every credential again, because the attacker may have captured them.

Afterwards: find the entry point (old plugin, reused password, ex-volunteer account), fix it and write a short factual note.

Put contact numbers for your host, registrar, payment provider and developer in the plan, since you may not be able to look them up on your own site if it is down.

Volunteer handover and offboarding

NGOs have volunteers, interns and part-time developers who come and go. Each departure is a security event.

Offboarding: disable the person's WordPress account and reassign posts; remove them from hosting, DNS/CDN, payment dashboard, email admin and repository; rotate shared secrets they knew (API keys, SMTP, database passwords); confirm deletion of any donor exports; update the access register.

An access register is simply a spreadsheet: name, role, systems, date granted, who approved, date removed. Review it every quarter. It looks bureaucratic until the day you need to know who still has admin access.

A quarterly security checklist

Put this in the calendar with a named owner; it takes 45 to 60 minutes.

• Access register reviewed; leavers removed; two to three administrators, each with 2FA; recovery codes in the shared vault.
• Domain, hosting and payment accounts are in the NGO's name, with auto-renewal and a valid payment method.
• Core, plugins and themes updated; unused ones deleted; TLS renewal working.
• Latest backup exists and is offsite; a restore test was done in the last six months.
• Payment dashboard checked for clusters of small failed attempts; firewall and rate-limit events reviewed; test donation made in test mode.
• Old donor exports removed; log retention and incident-plan contacts checked.

Working with Govindani Infotech

We are a web design and development company in Pune and we build and maintain donation websites for non-profits across India. If you run an NGO site and are unsure who owns the domain, whether the last backup could actually be restored, or how your donation form would cope with a card-testing burst, we can review the setup and give you a plain list of what to fix first and what can wait.

If you are planning a new site, see our website creation services, and the NGO page explains how we approach non-profit projects. Message us on WhatsApp or use the contact page. Please share your site address and platform (WordPress or custom), and do not send passwords by message; we will never need them for an initial review.

Frequently Asked Questions

Is a small NGO website really a target for hackers?

Yes, mostly through automation. Scripts scan for outdated plugins, weak passwords and open forms regardless of who owns the site. Donation forms attract extra attention because card-testers look for forms with few checks.

Does using a hosted payment page make my donation site secure?

It removes the biggest risk, which is handling card numbers yourself, but it does not secure everything else. Your admin logins, domain, email, plugins and donor records still need protection, and your form can still be abused by bots.

How often should we back up a donation website, and how do we know the backup works?

The WordPress documentation suggests weekly backups for small sites and daily for busy ones; if donations arrive daily, back up the database daily. Keep at least one copy outside your hosting account, and restore to a staging site at least twice a year to prove it works.

Who should own the domain and hosting account of an NGO?

The NGO itself, registered in its legal name with an organisational email and 2FA, and with at least two trustees able to access it. Developers and volunteers should be added as users with removable access, never as the owner.

Do we have to report a website hack to CERT-In?

CERT-In's April 2022 Directions require reporting listed incident types, which include unauthorised access, defacement and data breaches, within six hours of becoming aware. Whether and how this applies to your NGO is a legal question, so confirm with an adviser, and keep logs so you can describe what happened.

Sources:

• https://developer.wordpress.org/advanced-administration/security/hardening/
• https://developer.wordpress.org/advanced-administration/security/mfa/
• https://developer.wordpress.org/advanced-administration/security/backup/
• https://wordpress.org/documentation/article/roles-and-capabilities/
• https://developers.cloudflare.com/ssl/edge-certificates/additional-options/http-strict-transport-security/
• https://developers.cloudflare.com/waf/rate-limiting-rules/
• https://developers.cloudflare.com/waf/managed-rules/
• https://neonone.com/resources/blog/understanding-and-combating-credit-card-testing-attacks/ (secondary)
• https://www.idonate.com/blog/how-to-prevent-donation-page-credit-card-testing-fraud (secondary)
• https://letsencrypt.org/docs/faq/
• https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
• https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html
• https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
• https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
• https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf