Report a vulnerability

Found a way to read data that is not yours, to get around a permission or to take the API down, write to dev@fatureihoje.com. The same goes for a flaw you ran into by accident, in the middle of an ordinary integration.

The address

dev@fatureihoje.com

It is the same address published in the API’s security.txt:

https://api.fatureihoje.com/.well-known/security.txt

The file carries the contact, its expiry date, the accepted languages and the canonical address:

Contact: mailto:dev@fatureihoje.com
Expires: <ISO 8601 date>
Preferred-Languages: pt, en, es
Canonical: https://api.fatureihoje.com/.well-known/security.txt

That is the only path on the API host that does not start with /public/v1. Every other path answers 404.

Write in Portuguese, English or Spanish.

What to send

• The steps to reproduce, from start to finish, without skipping any.
• The exact call: method, path and, if there is one, the body.
• The request_id of the call. It comes in the Request-Id header of every response and in the request_id field of the error body. It is what lets us find your exact call.
• Date and time, with the time zone.
• What you expected and what happened.
• The visible prefix of the key, the first 14 characters (fh_live_ plus 6). It identifies the key without revealing it.
• What the flaw allows, in your assessment.
• If you did see data that is not yours: say how much you saw, and stop there.

What not to send

• The key in plain text. Not in the body of the email, not in a screenshot, not as an attachment. The prefix is enough for us to know which key it is. If the key already went through a channel you do not control, revoke it before writing.
• Customer personal data beyond the minimum needed to reproduce.
• Executable attachments.

What not to do while testing

There is no test environment. The API that answers is the production one, with real data belonging to real people.

• Do not test on another company’s data.
• Do not run load tests or automated scanners. The per-minute request budget and the per-address authentication failure cap answer 429, and that 429 is not a security flaw.
• Do not use the flaw for anything beyond confirming that it exists.

What we publish about this

We do not publish a response time. There is no security SLA written on this page, and we are not going to write one that was not agreed with you. If your report has a date attached (a scheduled disclosure, an audit under way, a customer waiting), say so in the first email.

There is no reward programme. No payment for reports, today.

What the documentation guarantees about the behaviour of the API is described on the other pages, and what changes in the contract is in Versions and changelog.

A flaw that is not about security

An integration error, a response you were not expecting, a question about the contract: use the support Contact. Same address, different list of what to have at hand.

Next step

• Contact: what to gather before writing about an integration error.
• API status: how to tell whether the problem is yours or ours.
• Key best practices: what to do if the key leaked.