How I Secured the Endpoints of the Website

Saniya Fatima -

I’m Saniya Fatima, currently a Sophomore.

This blog covers a recent issue I worked on, "Securing the endpoints of the Point Blank Website".

Endpoint security might sound complex at first, but at its core, it’s about making sure that the right people have the right access. Here are the challenges faced and the solution that secured all the endpoints of the website.

What Does Securing Endpoints Mean?

To understand endpoint security, it’s important to first know what an API is.

Understanding APIs

Whenever a website performs an action (like fetching or updating data), it communicates with the server through an API call.

  • API (Application Programming Interface): Acts as a middleman between services.
  • To communicate, APIs usually use the HTTP protocol.

And these requests can serve different purposes depending on the operation:

  • GET → Retrieve data
  • POST → Add data
  • PUT / PATCH → Update data
  • DELETE → Remove data

Why Endpoint Security Matters?

The API endpoint is the exact URL to which a request must be sent to access a specific resource.

For example:

  • /users → might fetch a list of users (GET)
  • /orders → might allow placing a new order (POST)

While many endpoints (like GET) may be publicly accessible, sensitive actions such as POST, PUT, or DELETE should only be performed by authorized users.

Endpoint security ensures that only authorized users can perform sensitive actions, while unauthorized requests are blocked.

Wait....Authorization?

Landing into the trending question, the difference between authentication and authorization.

  • Authentication → Confirms who the user is.
  • Authorization → Decides what that authenticated user can do.

Approach

Our website already used Firebase Authentication, so the most efficient way to secure endpoints was through the Firebase Admin SDK.

Here’s the flow:

Authorization Flowchart
  1. When a user tries to perform POST, PUT, or DELETE, their account’s UID is checked server-side.
  2. If valid, Firebase generates an Authorization Token.
  3. Only then the user is allowed to proceed with that action.

This ensures CRUD operations are restricted to the right users.

The Unexpected Issue

I started by referring to the Firebase Documentation, implemented the logic and tested it locally, everything worked fine. So, I raised a PR to staging branch.

But then, it didn’t work as expected.

The authorization token wasn’t getting attached to the requests, which meant even authenticated users couldn’t perform CRUD operations.

What was the issue?

  • Logs revealed: “Firebase service account environment variable is not set.”

I had already set it in GitHub Secrets, so what went wrong?

Turns out, it was a very silly mistake -> Extra spaces in the environment variable! 😅

After fixing it, tests ran successfully and endpoints were now secured.

Double Checking

But was it really secure?

Along with my senior Aswin bhaiya ,all the routes were tested. Most endpoints were secure but we found another loophole:

  • Problem: Email domain validation was only happening client-side.
  • Impact: Malicious users could bypass it and receive sign-in links on unauthorized emails.

Final Fix

To close this gap:

  1. Strengthened Firebase security rules.
  2. Added Server-side validation of email domain.

After multiple rounds of testing, we confirmed:
ALL THE ENDPOINTS OF THE WEBSITE ARE SECURED!!!!!

Conclusion

It’s not enough for endpoints to work, they must work securely. Sometimes, the smallest issues (like an extra space in an environment variable!) can break the whole flow.

This experience taught me that:

  • Both authentication and authorization must be properly enforced.
  • Never rely solely on client-side checks.
  • Test, test and test again.