On September 11th, we discovered that resumes that had been submitted from 460 individuals to TokyoDev were accidentally made public to the Bing search engine. If yours was one of them, you should have already received an email about this. We’ve fixed the root cause of this and had Bing remove the URL and their cache of it. No further action is required on the part of anyone who was affected.
This article will explain who was affected, why it happened, and what actions we’ve taken in response.
Who was affected by this?
To be affected by this issue, you needed to:
- Have submitted a resume to TokyoDev’s site between on or before September 11th, 2025. (Those submitting it directly via our clients’ own applicant tracking systems were not affected.)
- Have had the resume viewed on the site, either by you yourself, or through our administrative interface.
Resumes submitted as part of a job application are normally directly forwarded to the company as an email attachment. If a resume was not also viewed on the TokyoDev site, it was not affected.
What was the cause?
On December 4th, 2024, we began proxying uploaded files via our web application, and caching the result in Cloudflare. This caching would happen on demand when the uploaded file was accessed via our website. The intention was to improve performance for publicly-displayed things like a company’s logo on the job board, but other internal resources, such as resumes, were cached in this manner.
We made this change without realising we had previously activated Cloudflare’s Crawler Hints feature. This feature uses the IndexNow protocol to send URLs to search engines for indexing. As this feature is applied to anything Cloudflare caches, the resume URLs were also sent for indexing.
According to IndexNow’s homepage, the protocol has support from Microsoft Bing, Naver, Seznam.cz, Yandex, and Yep. We’ve searched on all these for the resumes, but were only able to find them indexed on Bing.
Bing fetched all our uploaded files for indexing, including resumes. As the only mechanism we had in place to prevent access to these resumes was a unguessable URL, they were able to retrieve the resumes and index them.
What actions have we taken?
As of today, we have:
- Added proper access control for the resumes. You can no longer view a resume without being first logged into TokyoDev, so even if the URL to a resume became publicly available again, the content wouldn’t be accessible.
- Disabled the Crawler Hints feature of Cloudflare.
- Used Bing’s “Block URLs” feature to remove the resume URLs from their cache and index.
- Made a report about the incident to Japan’s Personal Information Protection Commission via their leakage report form. Japan’s Act on the Protection of Personal Information requires this under certain circumstances. We consulted a lawyer, who said this incident didn’t meet such requirements, but decided to err on the side of caution and disclose it anyway.
- Hired an external security consultant to audit our Ruby on Rails application. This incident could have been prevented if we had followed a more secure strategy for accessing the resumes in the first place. Having an outside auditor will help us identify other improvements we can make.
- Discontinued the manual importing of job applications into companies’ Applicant Tracking Systems (ATS). For one of our clients, when they received an application via TokyoDev, I would manually download the resume and then reupload it into their ATS. This was done at the direction of one of their hiring managers, who felt TokyoDev’s application form offered candidates a smoother experience than their own ATS. However, since a manual process like this introduces human error, I’ve now discontinued it. All applications will be made either via the company’s own ATS, or automatically sent by email.
Our takeaways
Relying on an unguessable URL can lead to data leaks
Besides the particular issue we encountered with an unguessable URL, there are other potential problems with this approach. For instance, the path of a request appears in our logs. This means that a developer with access to our logs could have also gained access to specific resumes. Currently only people with access to the production environment can see those, but this is an example of something else that could change over time.
While the tradeoffs here might be acceptable for something you do want to share widely without authentication, such as a Google document via the “share with anyone with a link” feature, it shouldn’t be used for protecting resumes when you can instead restrict access to those with something like a logged-in account.
Applications get less secure over time
We’ve done our best to be security conscious with TokyoDev, by following best practices, using a web framework with security baked in, and running automated tools to detect security vulnerabilities within our application.
Reflecting on it, our application has become more insecure over time for a simple reason: it has gotten more complex. TokyoDev was originally a site generated using Middleman, which takes data files and template files and produces static HTML. As there was no user interaction involved, it was basically as secure as anything could be.
Over time, TokyoDev’s site has grown. We built a standalone Ruby on Rails application for handling job applications. That standalone application became the data source for Middleman, and then later replaced Middleman altogether, so that now the site is a single Ruby on Rails application. This allows us to do things like let companies add their job postings themselves, instead of us doing so manually.
All of this increased the complexity of our application. This complexity led to us making an oversight, which resulted in this vulnerability.
Years ago I wrote an article, “All code is technical debt,” in which I discuss this very issue. Ironically, I give the example of deciding not to make an application system for our job board. But while we can hold off on building software for a time, eventually it does become necessary.
So how do we counteract this problem going forward? We will start by augmenting our existing security processes with regular external audits.
Think carefully about what personal data you retain
We are not currently deleting job applications made on TokyoDev, for several reasons. For instance, we’ve had cases in which a company asked us to resend certain applications we’d already sent them. If we had deleted those applications, we couldn’t have done that.
In addition, TokyoDev is compensated when a candidate gets hired by a company. Usually a company will declare to us that they’ve made a hire; however, retaining the applications allows us to keep records of who has applied, and use that to enforce our agreement with them.
But this incident has me reconsidering the downsides. If we had deleted the resumes immediately after we had processed the job applications, it would have reduced the scope of this vulnerability.
I don’t have a final answer yet, but I do think we’ll be more conservative about what data we retain going forward.
Incident Timeline
December 4, 2024
We started caching information in CloudFlare, which shared unguessable resume URLs via Cloudflare’s Crawler Hints feature.
September 11, 2025
I received an email from someone who had applied for a job via TokyoDev, stating that their resume on TokyoDev was accessible by “AI robots” and asking me to remove it from our system.
I replied to them that I had deleted their resume, and asked for more details to try and identify the underlying issue.
They shared that they had asked Microsoft Copilot to search for their own resume, and it had returned it. I realized that Copilot used Bing for search, and was able to find this person’s resume, and others from TokyoDev, indexed on it.
I began investigating myself, but wasn’t immediately able to figure out the cause. So I contacted one of our other developers, who pointed out it may have been caused by Cloudflare sending URLs to Bing for indexing, something we confirmed to be the case.
We quickly deployed a fix that would have the existing resume URLs return 404s, and began undertaking more exhaustive improvements.
I also sent a support request to Cloudflare regarding this.
September 12, 2025
We consulted with a lawyer about our responsibilities under Japan’s Act on the Protection of Personal Information and voluntarily submitted our initial report to Japan’s Personal Information Protection Commission.
As Cloudflare had not yet responded to my request, I upgraded our plan from Pro to Business for prioritized support.
As the URL pattern had changed when we began caching resumes through Cloudflare, I queried our logs using the new pattern and identified 484 resumes associated with 460 unique email addresses that had been accessed during the incident.
September 13, 2025
As although the indexed resume URLs returned 404 but Bing’s index still had a cached version of them, I used Bing’s Block Tool to manually block the results that we could crawl from being included in their index and cache.
September 15, 2025
After confirming the Block Tool requests had been successfully processed, some other results remained. Rather than relying on scraped results, I submitted a block request for every resume URL that was accessed since this incident first occurred.
September 18, 2025
I verified that Bing was no longer showing any resumes in their search results.
As Cloudflare still hadn’t replied to my request, I used their chat support to get them to escalate the ticket. They wouldn’t tell me when they would respond.
September 22, 2025
We informed every person affected by this issue and published this article.
I submitted the final report of this incident to Japan’s Personal Information Protection Commission.
We submitted vulnerability reports to Cloudflare and Ruby on Rails via their HackerOne pages about this issue, pointing out the insecure defaults they had.
September 23, 2005
Acting on behalf of Cloudflare, HackerOne closed our vulnerability report as “Not Applicable”, stating Cloudflare already provides a means of excluding certain files.
September 24, 2025
Cloudflare responded. They pointed out that part of the Index Now protocol is that all participants exchange information, implying that it didn’t matter where they sent it. They were unable to tell us when we first enabled this feature.
Taking a second look at the Index Now documentation, I saw that Amazon also supported IndexNow, and uses it for AmazonBot. This index is used by Alexa among others. As there is no search frontend for Alexa, I was unable to ascertain whether they were indexing our files. I did send an email to them requesting they remove any pdf files from our site from their index. They still haven’t responded to that.
I remembered that on May 13, 2025 we were being DOSed by Amazonbot, with them repeatedly requesting a URL for our job search. I configured Cloudflare to block Amazonbot. So they could have at most indexed resumes that were sent via IndexNow between December 4, 2024 and May 13, 2025.
October 8, 2025
Ruby on Rails closed the issue we reported via their HackerOne page “as there’s no specific bug and the issue is already public”. I opened a PR to provide a stronger warning about their insecure framework default.
October 9, 2025
We received the Ruby on Rails security audit result.
It included one critical issue that could have potentially lead to any file on the server being returned (including /etc/passwd) but was mitigated by a secure token protecting access to that. Nevertheless, as this was dead code that we were no longer using it, we deleted it.
It also included 4 more less serious issues, and another 10 points where we could strengthen or improve things.
We put all of these issues into our backlog, and are working to rectify them.
Conclusion
I apologize to everyone whose resume we accidentally disclosed. You trusted us to secure it, and we let you down.
Over the past week and a half, we’ve reviewed potential vulnerabilities and put additional measures in place to keep improving TokyoDev’s security practices.
Most of you reading this are developers yourselves. By being open about our mistake, I hope others can learn from us and avoid making the same ones.
