Security: Implement missing authToken middleware on critical REST endpoints#200
Open
anushkakannawar wants to merge 1 commit into
Conversation
Contributor
|
@anushkakannawar is attempting to deploy a commit to the Sunil Kumar's projects Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A security audit of our backend routing has revealed multiple critical API endpoints that currently lack authentication gatekeeping. Unauthenticated users can access these routes directly, posing severe risks including message spoofing, unauthorized data exposure (chat history leaks), and unauthorized modification of server structures (channels/categories/invites).
While a robust authToken middleware exists within auth.js, it is not universally applied. This change tracks the immediate containment of these security gaps by attaching the middleware to the completely unprotected routes.
Affected Routes & Risk Assessment
chat.js — POST /store_message
Risk: 🔴 Critical. Anyone can send messages impersonating any user.
chat.js — POST /get_messages
Risk: 🔴 Critical. No auth check; anyone can read any channel's historical chat logs.
chat.js — POST /toggle_server_message_pin
Risk: 🟠 Medium. Uses inline token parsing but lacks a strict middleware gate.
servers.js — POST /add_new_channel
Risk: 🔴 High. Allows unauthenticated structural modification of any server.
servers.js — POST /add_new_category
Risk: 🔴 High. Allows unauthenticated structural modification of any server.
invites.js — POST /create_invite_link
Risk: 🔴 High. Unauthorized creation of server invites.
invites.js — POST /invite_link_info
Risk: 🟡 Low/Medium. Information leak revealing server metadata.
invites.js — POST /accept_invite
Risk: 🔴 High. Allows anyone to join any server without verification.
1.Proposed Changes
chat.js
Import the authToken middleware.
Secure POST /store_message, POST /get_messages, and POST /toggle_server_message_pin. (Note: For backward compatibility, /store_message still reads sender credentials from req.body for now, but is now strictly gated by authToken).
servers.js
Import the authToken middleware.
Apply authToken to POST /add_new_channel and POST /add_new_category.
invites.js
Import the authToken middleware.
Apply authToken to POST /create_invite_link, POST /invite_link_info, and POST /accept_invite.
2.The Proposed Solution
To solve this, we applied the pre-existing authToken middleware to guard the unprotected endpoints.
When an API request is made to any of these secured endpoints:
The server intercepts the request before it reaches the main handler.
It looks for a token inside the x-auth-token header.
If no token is provided, or if the token is invalid/expired, the server immediately halts the request and returns a 401 Unauthorized status code.
If the token is valid, it decodes the user's account details, attaches them to the request context, and allows the request to execute safely.
3.Detailed Changes by Module
Chat Module
Sticker/Message Storage: Secured the endpoint that saves incoming chat messages. Now, the sender's token must be verified, preventing anonymous users from spoofing messages.
Retrieve Messages: Secured the endpoint that fetches channel histories. Now, only users who present a valid authentication token can download and read messages.
Pin Message: Secured the message pinning toggle. The request must go through the authentication check first.
Server Management Module
Create Channel: Secured the endpoint that adds new text/voice channels to a server. Now, only authenticated users can attempt to add channels.
Create Category: Secured the endpoint that adds structural categories. This prevents unauthorized users from altering server layouts.
Invitation Module
Create Invite Link: Secured invite link generation. Only authenticated members can create invites.
Invite Information Lookup: Secured the endpoint that extracts server metadata from an invite code. This stops bots or unauthorized users from scraping server names and assets.
Accept Invite: Secured the join-server action. Only verified, logged-in accounts are permitted to join servers using an invite code.
4.Verification
The authentication system was validated using the backend's internal unit tests to ensure that the token verification logic behaves correctly and does not break existing features.
To verify manually:
Sending a request to these endpoints without the header yields a 401 Unauthorized response.
Sending a request with a valid token allows the action to complete normally.