# Remove Sensitive Contact Info & Credentials from Tweets

> Passwords, API keys and card numbers get posted by accident more often than people think. How to search your own history for them.

- Source: https://tweetsweep.com/blog/delete-tweets-remove-personal-contact-information
- Published: 2026-08-04
- Reading time: 6 min

---
## Delete the Tweet First

If you just realised that a tweet carries a password, API key or credit card number — Delete. That. Tweet. Do not take a screenshot, do not copy the text, do not sit and wait. X's api limits each user to 50 requests every 15 minutes but deleting a single tweet is, on the contrary, equal to one request and takes less than a second. We are talking about an absolutely picky issue here, I'd say that the biggest priority is to get rid of the credential from public view before someone archives it, take a screenshot of it or index it. As soon as passwords are deleted, use a different password for every account that used it, deactivate the leaked API key and change to a new one, contact with your bank if there was a credit card number involved. With the corporate credentials, inform the security team as soon as the tweet is gone. The only thing that you can control is speed.

Despite deleting something from your account, the risk continues with regard to X's internal archive and third-party archive services like the Wayback Machine, as well as screenshots or quote tweets others may have done. Even a tweet that was public for mere minutes may be archived somewhere. When you delete the original, this removes its primary source from being indexed more but not those copies. If you deleted in a matter of minutes, it less likely got scraped. If it took hours or days, assume you were scraped. In either case, delete, since that is the first step in that it removes the most low hanging fruit for anyone searching old tweets for credentials.

## Search for Credential Patterns

With TweetSweep you can scan your entire timeline against common formats used in credentials. Configure search regex for "password: api_key: access_token: secret: db_connection: ssh-rsa" Search for actual key format patterns such as:40-character alphanumeric strings GitHub tokens20-character base64 strings AWS secret keysStrings that start with sk- or pk- Stripe API keys So don't search for the word password on its own, because you just get back thousands of benign tweets about what their password policy is. Instead, make a combination of prefixes with probable suffixes such as password is, password = and password:

In credit card numbers, look for 16 digits or the sequence "4111" (a common test number) followed by any 12 digits. For social sec numbers, 9 digits with hyphens in the standard seq. Search for strings matching the phone numbers "555-" or "+1[digits]" While being thorough, but realistic: you want real disclosures, not every tweet with a number in it. If you were in tech support [again], pay attention to the tweet that reveals your private IP address because you copy-pasted a real server address, or database string. If you were in finance, target tweets that talk about a transaction or account.

## Use code snippets in technical tweets

The risk of credential exposure is highest for software engineers and technical professionals, as their code snippets usually have hardcoded keys, connection strings or environment variables in them. Search for all tweets in which you shared a code snippet, including GitHub Gist embeds, Pastebin links or just straight-up blocks of code Even if this snippet was written as a toy example, you might have introduced your real API key from a A real database hostname from either an env file or a config file. Search for strings like "config. ini", ". env", "credentials. yml", or "secrets. Please remove the extra stuff (eg: json which probably you pasted by mistake.)

And also look for tweets containing terminal outputs or screendumps of debuggers, typically these will leak some environment variables, command line parameters, or paths on the file system that would have hidden credentials. Similarly, if you tweeted a screenshot of an error message that contained a link to the database URI or server address, now that counts as disclosure. Most companies have specific policies about the sharing of internal configuration information, and even a tweet from 10 years ago could be instrumental in social engineering your current employer. Every 3 months do an audit of your technical history, and for any code snippet that you have written which has a placeholder or example (like num of threads?) test it: the tweet connect to db with user=admin pass=12345 even though it is just an example will hurt you if you intended it.

## Understand the 3,200-Tweet Ceiling

X restricts API access to only the last 3,200 tweets of each user. Note: TweetSweep can only scan the latest 3,200 tweets if your Tweet history is above that. However, all previous tweets are stored on X's servers but not retrievable through bulk operations via the API. As for finding credentials in those older tweets, there are two ways to do so: you can either order your whole X archive via the Settings menu (this creates a ZIP file of all of your tweets that you can download) or search specific terms manually on the web interface. The archive takes a maximum 48 hours to produce but has every tweet you ever tweeted, even those that goes beyond the 3,200 limit.

After you have the archive, you can locally search it with a text editor or script to hunt for credential tags. This is boring but essential for long-term users. Now, you have to remove tweets from the web interface one after another for affected tweets as they will not be returned by the API. Give priority to tweets containing the most critical information: API keys, passwords and financial data. Age doesn't mean reduced risk, either; evidence of a 2015 tweet still turns up in X's search and third-party archives. If your history exceeds the API ceiling, allocate some budget time for this manual cleanup.

## Protect Against Social Engineering Attacks

Furthermore, even deactivated or modified credentials that are publicly accessible pose a rollback social-engineering attack risk. With an outdated API key leaked by your tweets, an attacker can know about you or your current company, its domain as well as the projects that you currently work on. They may then pass your IT department off as you referring to information from the old tweet in an attempt to seem convincing. If, say, you tweeted a database connection string from a consultancy five years ago, anyone could have the hostname and your real name to tailor an easily believable phishing email to your current firm (at help@artofmalware.com).

This surface area is removed by taking down the tweet. There is more than just rotating the credential, though—you have to delete the original disclosure. Social engineering tactics do work in part because they blend public domain information with private details that suggest identity validation. Something that has a lot of technical information along with personal context (e.g., date-of-birth, favourite colour, pet name) in one tweet is a treasure trove for attackers. Find any tweet that combines a credential with personal information and delete it. This is true for all your credentials, including those you consider expired or test-only.

## Establish a Regular Audit Routine

Every three months, scan your timeline for credential leaks and set up a recurring reminder. Apply TweetSweep on the same search patterns you recognized at the original scanning time. Tweets become obsolete yet accumulate, your searches evolve as you take on new jobs or begin to use new services and with new tools. If you store your search patterns as templates — a quarterly scan takes < 5min). Tweet at least every month if you tweet a lot about technical things. Sometimes they hope to catch a leak prior to anyone archiving it, within the 50-request window that you can delete swiftly.

Prevention is better than cleanup. Run any code snippet you tweet through a credential masking script, or simply replace sensitive and real values with "YOUR_API_KEY_HERE". Never tweet a screenshot of terminals without checking output for credentials, and never include. JSON files and.env files (or piggybacking on public codebase settings files) If you expose technical knowledge, provide dummy credentials that are clearly falsified: 'password: test123' or 'api_key: abc123def456'. Not only does this model good security posture for then to peer off of, it also shields you from inadvertently exposing sensitive data. A five second assessment before publishing can save hours cleaning out the mess and prevent a security breach.