> ## Content Index
> Fetch the complete content index at: https://securinglaravel.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Security Tip: Fix Your Leaky APIs!
- URL: https://securinglaravel.com/security-tip-fix-your-leaky-apis/
- Published: 2024-02-07T04:00:28.000Z
- Updated: 2025-05-11T08:50:50.000Z
- Description: [Tip#70] This is your periodic reminder to check your app for any leaky APIs and fix them ASAP, otherwise you might end up with an email from Have I Been Pwned's Troy Hunt...
- Author: Stephen Rees-Carter
- Tags: Security Tips, APIs, Leaking Data, PII

We’ve covered this topic before, with [Sensitive Model Attributes](https://securinglaravel.com/security-tip-sensitive-model-attributes/), and [Leaking Data After Changes](https://securinglaravel.com/security-tip-leaking-data-after-changes/), but in light of the [*Spoutible*](https://spoutible.com/?ref=securinglaravel.com) data breach, which was [loaded into Have I Been Pwned](https://haveibeenpwned.com/PwnedWebsites?ref=securinglaravel.com#Spoutible) (HIBP), I felt it was a good time for a reminder.

Firstly, if you’re unfamiliar with the breach, [Troy Hunt has written up a great post outlining what happened](https://www.troyhunt.com/how-spoutibles-leaky-api-spurted-out-a-deluge-of-personal-data/?ref=securinglaravel.com), and I highly recommend you give it a read. It’s one of these stories that just keeps getting worse and worse, the more you read!

Regarding the actual data breach, here’s the summary from HIBP:

> *In January 2024, Spoutible had 207k records scraped from a misconfigured API that inadvertently returned excessive personal information. The data included names, usernames, email and IP addresses, phone numbers (where provided to the platform), genders and bcrypt password hashes. The incident also exposed 2FA secrets and backup codes along with password reset tokens.*

Yes, you read that right: *Spoutible* had an API endpoint which returned:

- names
- usernames
- email addresses
- IP addresses
- phone numbers (if provided)
- genders
- bcrypt password hashes
- 2FA secrets
- 2FA backup codes
- password reset tokens
- And more…

We’re talking a whole boatload of Personally Identifiable Information (PII) and Authentication Data, which would be incredibly useful for stealing identities, hijacking user accounts, and a bunch of other malicious activities! The sheer amount of data available in this breach, especially via an API like this, is rarely seen.

While Troy’s post doesn’t answer the “*Why was this data available?*” question, it’s pretty easy to assume that the folks who built the API did something like this:

```
class User
{
    public function index()
    {  
        return User::all();
    }

    public function show(User $user)
    {
        return $user;
    }
}
```

Unless protections are put in place, these controller actions will return **everything** on the user model. This may include all sorts of PII and auth data, such as what happened with *Spoutible*. That said, Laravel does give us some tools and helpers for avoiding this in our own apps, so protecting against it is easy - as long as you’re intentional with your data and your APIs.

**Here are my recommendations:**

1. Use `$hidden` to protect sensitive attributes from being returned via `toArray()`, and `toJson()`, etc.  
*See:* [*Security Tip: Sensitive Model Attributes*](https://securinglaravel.com/security-tip-sensitive-model-attributes/)
2. Use `only()` on the model or collection to limit the returned attributes on a per-request basis.  
*See also:* [*Security Tip: Leaking Data After Changes*](https://securinglaravel.com/security-tip-leaking-data-after-changes/)
3. Use [API Resources](https://laravel.com/docs/eloquent-resources?ref=securinglaravel.com) and manually define each returned model attribute.

**Don’t forget:** This doesn’t just affect public APIs, but it can also occur for internal APIs used within SPAs, or even components that serialise model data into attributes. Any time you’re sending data to the browser or over an API, be aware of who can access it and what data is being sent!

---

***If you found this security tip useful,*** [***subscribe***](#/portal/signup) ***to get weekly*** [***Security Tips***](https://securinglaravel.com/tag/tips/) **straight to your inbox.* Upgrade to a* [*premium subscription*](#/portal/signup) *for exclusive monthly* [*In Depth articles*](https://securinglaravel.com/tag/in-depth/)*, or drop a coin in the* [*tip jar*](#/portal/support) *to show your support.*

*When was the last time you had a penetration test? Book a* [*Laravel Security Audit and Penetration Test*](https://stephenreescarter.net/laravel-security-audits-and-pentesting/?utm%5Fsource=securinglaravel.com)*, or a budget-friendly* [*Security Review*](https://stephenreescarter.net/laravel-security-reviews/?utm%5Fsource=securinglaravel.com)*!* 

*You can also connect with me on* [*Bluesky*](https://bsky.app/profile/valorin.bsky.social?ref=securinglaravel.com)*, or* [*other socials*](https://pinkary.com/@valorin?ref=securinglaravel.com)*, and check out* [*Practical Laravel Security*](https://practicallaravelsecurity.com/?utm%5Fsource=securinglaravel.com)*, my interactive course designed to boost your Laravel security skills.*