Story of critical security flaws I found in Glints

2022-02-10: Update title from "How I hacked Glints and your resume" to "Story of critical security flaws I found in Glints"

Glints is a job search platform based in Singapore, and they just got a 20M investment last year, they have a team in Taiwan as well.

In July 2021, I found Glints bug bounty program so I spent some time on it, and I found 4 vulnerabilities in total in the end.

The vulnerabilities I found could have:

  1. Stole every applicant's personal information, including name, phone, birthday, resume, and email
  2. Stole every recruiter's personal information, including name, job title, team name, and email

In other words, the attacker can steal all users' information by exploiting the vulnerabilities.

Let's see what it is.

# 1. Job application IDOR leads to user information exposure

There are two roles at Glints: employee and employer. For now, anyone can create an employer account, but still need to do the verification when posting new jobs.

For sure, there is a portal for the employer to manage jobs and candidates:


Here is the API for checking job applications:/api/recruiterats/jobApplications?where={"JobId": "55e137a1-f96e-4720-9b08-7eb2749e1557"}

Part of API response:

"candidate": {
"id": "44007523-f7a8-411d-b2c4-57c68a976534",
"profilePic": "6f14ffc62f3f53d8dcb22a4bfc1da6c8.png",
"firstName": "Peter",
"lastName": "劉",
"email": "",
"phone": "+886-999999999",
"resume": "bb042b7400c444659fdedf79a9c8daf3.pdf",
"salaryExpectation": null,
"currencyCode": null,
"recentJob": {
"title": "工程師"
"lastSeen": "2021-07-22T01:58:14.859Z",
"country": "Taiwan",
"city": "Taipei"

In the response, there are applicant's name, email, phone and resume file name.

After seeing the API URL, I did one thing which all pentesters will do: change JobId to another one which belongs to another company, and to my surprise, it works:


We can find JobId easily because it's public, we can find it in the URL like this:

If I were an attacker, I can write a script to fetch all the job ids from Glints, and exploit the vulnerability to get all personal data from all applicants.

# Remediation

Glints fixed the vulnerability by checking JobId and implementing correct access control.

# 2. RSS feature IDOR leads to user information exposure

Glints has a "RSS feed" feature to let users connect to Slack or other services:


There are the applicant's name, email, and resume in the response:

rss content

Here is the RSS feed url:{RSS_ID}/approved-candidates?UserId={companyOwnerId}

To forge the URL, we need the correct RSS_ID for the specific job and user id as well. It's easy to get user id because company information is public, but how about RSS_ID?

I found that there is an API for getting jobs from certain companies:{"status":"open"}&include=jobSalaries,Groups,City,Country

I guessed they used a Node.js ORM called Sequelize in back-end because I am familiar with this library and I found that the naming convention for query string is similar to it.

Then, I tried to add a few parameters but most of them did not work, except for one important parameter: attributes.

This field decides what to return from Sequelize, for example, attributes=id means it returns id field only in the response. So, I put rssId in the attribute field, and it works:


By sending this parameter, we can get job id, rss id, and company owner's id, then we can query RSS feed to get all applicant's data.

# Remediation

Glints remove this feature entirely because of low usage.

# 3. User information exposure

For vulnerability #1 and #2, only employer accounts can exploit it. But for this one, anyone can.

After registering an account on Glints, you will have a user id and a public profile page, like this:

public page

44007523-f7a8-411d-b2c4-57c68a976534 is my user id which is also shown on the URL.

There is another API for getting user profile:

profile api

Sensitive information has already been filtered, like phone and email. But, one column has been forgotten: resume. Resume field represents file name only, like badf34128adefqcxsq.pdf, and Glints stores all the resumes in the same place, the URL rule is:

In other words, by just knowing the file name of the resume, we can download the file directly. If I know someone's user id, I can get their resume by exploiting the API we just mentioned, and it usually contains personal data like email, phone, even address.

Now, how do we find a bunch of user id?

We can do it by google hacking!

Because all the public profile page has the same URL pattern, google this keyword can help you to find a lot of user profile page and user id: inurl:profile/public Then, we use these user ids to get their resume.

google hacking

# Remediation

Glints remove sensitive fields like resume from the response.

# 4. Recruiter information exposure

By far, we talked about the vulnerabilities of employees only, let's see a different vulnerability.

I scanned the subdomain of and found an interesting page:


It requires a Google account with a certain suffix, so we can't log in. But, we can find some clues in JS file! Usually, those files are minified and hard to read, but we can use the search function on Chrome Devtool. For example, I searched for "query":

search query

From the results, you can see a GraphQL query called findRecruiters, the parameters are also available in source code:

query {
findRecruiters(input:{}) {

team {

In response, there are the name, job title, team, and email of every single recruiter:

# Remediation

Glints implemented access control, a guest is unable to access this query anymore.

# Summary

Most of the vulnerabilities I found are about access control. When access control is broken, it's easy to access others' data. It's not a good thing for job platforms like Glints, because there are name, email, phone, even address in a resume.

That's why all 4 vulnerabilities are identified as high-risk issues, worth 1600 SGD bounty in total.




  1. SSRF and Account Takeover via XSS in ERPNext (0-day)
  2. Cache Strategy In Backend
  3. Understanding Log4j and Log4Shell Vulnerabilities from Surveillance Cameras
  4. Java’s Thread Model and Golang Goroutine
  5. The Difference Between Java and Golang in Writing Concurrent Code to Access Shared Variable

Discussion(login required)