Back to site

WP Charity – Observations

High – Excessive User Permissions Leads to Site Defacement

Any registered user can create a post on the donate.melloneducate.com site.

NOTE: The screenshots are showing users with a “Volunteer” role, not any registered user. While this is by design, as Volunteers need to create Campaigns (which are custom post types), I have removed the Dashboard access for Volunteers.

See changelog.

High – Unrestricted File Upload

https://donate.melloneducate.com/volunteer-portal

There is no restriction on file upload types within the volunteer portal when updating a user’s profile picture.

NOTE: I have added a check for images only.

See changelog.

High – Weak Password Policy

SRA was able to create a user with a weak password using a dictionary word and no special characters.

NOTE: This is not an issue, apps should not be enforcing passwords.

Strong password enforcement sounds like an obvious win—but in practice, it often creates more problems than it solves.

1. Users respond in predictable (and insecure) ways

When you force rules like:

  • 12+ characters
  • uppercase + lowercase + numbers + symbols
  • frequent expiry

Users don’t become more secure—they adapt:

  • Password1! → Password2! → Password3!
  • Writing passwords down
  • Reusing the same “complex” password everywhere

This actually reduces real-world security.

2. Complexity ≠ strength

Traditional rules (symbols, etc.) are outdated thinking.

A password like:

  • P@ssw0rd!23 → technically “strong”, but easily cracked
  • correct horse battery staple → long, simple, far more secure

Over-enforcement pushes users toward complex-looking but weak passwords instead of long, memorable ones.

3. It increases support and friction

Strict rules lead to:

  • More password resets
  • More failed logins
  • Higher support costs

For SaaS or WordPress products (like what you’re building), this directly impacts:

  • Conversion rates
  • User retention
  • Support load

4. Password expiration is actively harmful

Forced rotation (e.g. every 30/90 days):

  • Encourages minor variations
  • Discourages truly strong passwords
  • Creates fatigue

Modern guidance (e.g. National Institute of Standards and Technology) explicitly recommends not forcing periodic password changes unless there’s a breach.

5. It ignores the real threat model

Most compromises today come from:

  • Phishing
  • Credential stuffing (reused passwords from breaches)
  • Malware

Strong password rules do almost nothing against these.

What actually helps:

  • Breach detection (check against leaked passwords)
  • Rate limiting / bot protection
  • 2FA / passkeys

6. It discourages better alternatives

If users are already frustrated with passwords, adding strict rules:

  • Makes them resist security features
  • Reduces adoption of better options like:
    • Password managers
    • Magic links
    • Passkeys

7. It creates a false sense of security

Admins think:

“We enforce strong passwords, so we’re safe.”

But without:

  • login throttling
  • anomaly detection
  • 2FA

…it’s mostly security theatre.

High – Open Registration

Open registration is enabled on donate.melloneducate.com allowing any user to register an account.

NOTE: This is not an issue. This website requires user registration for Volunteers, where they can create Campaigns. It also requires user registrations for donations.

High – Externally Accessible Admin Portal

The WordPress admin portal is externally accessible.

NOTE: This is how WordPress works. I changed it to /4login on both websites. Read more below:

https://getbutterfly.com/why-changing-the-wordpress-login-url-is-a-bad-idea

Medium – User Enumeration

When submitting a logon request or password reset request the website will disclose if a user is not registered on the site.

NOTE: User enumeration is not a meaningful attack vector. There’s no access, no privilege escalation, no data leak — just confirmation of existence. I have changed it to a basic “Invalid login credentials”, but see why this is not a security issue:

1. WordPress already exposes usernames in multiple ways

Even if you hide login responses, WordPress leaks users elsewhere:

  • Author archives: /author/admin
  • REST API (if enabled)
  • RSS feeds
  • Public posts (author metadata)

So preventing enumeration at login is often security theatre, because the data is already accessible.

2. Emails/usernames are not secrets

Modern security assumes:

  • Emails are widely known / guessable
  • Usernames are often public

Real attackers don’t sit guessing blindly—they use:

  • Breach dumps
  • Social media
  • Public data

So hiding whether a user exists adds very little protection.

3. It significantly improves UX

Clear feedback:

  • “Email not found”
    vs
  • “Invalid credentials”

This matters a lot for:

  • Reducing friction
  • Avoiding user confusion
  • Lowering support requests

Especially for:

  • Non-technical users
  • SaaS-style WordPress products (like what you’re building)

4. It avoids unnecessary password resets

If you hide existence:

  • Users may try resetting passwords for accounts that don’t exist
  • This creates frustration and noise

Clear messaging:
→ helps users self-correct quickly

Low – Lack of Anti Scripting Controls

The form(s) do not have anti-scripting controls in place such as a CAPTCHA to prevent automated form submissions.

https://melloneducate.com/submit-your-own-photos-and-videos/

IE Volunteers 2026


IE Veteran Volunteers 2026


Student Volunteer Programme 2027


Literacy Hat Challenge

https://melloneducate.com/Contact/

NOTE: They actually do, and it’s Akismet, in the back-end. Visual CAPTCHAs are actually discouraged due to UX and accessibility issues. Hidden CAPTCHAs are preferred.

Low – Usernames/Employee Names in File Metadata

https://melloneducate.com/about/financial-transparency/

NOTE: The page is called “Financial Transparency“, so…

Also, this is content, if the client wants to publish their list of employees, it’s their prerogative.