Fix/follow log analytics poisoning#337
Merged
Harxhit merged 2 commits intoMay 27, 2026
Merged
Conversation
Harxhit
added
the
gssoc:approved
Collaborator
|
@Ridanshi Could please self review your PR I can see changes not valid for issue. |
Contributor
Author
|
Self-review addressed and branch updated. Changes are now scoped strictly to issue #301:
Verification:
Branch is updated and ready for re-review. |
Harxhit
reviewed
May 26, 2026
Collaborator
There was a problem hiding this comment.
If the changes are related to Follow.ts why this file?
Harxhit
reviewed
May 26, 2026
Collaborator
There was a problem hiding this comment.
If the changes are related to Follow.ts why this file?
Harxhit
reviewed
May 26, 2026
Collaborator
There was a problem hiding this comment.
If the changes are related to Follow.ts why this file?
… logs
POST /:platform/:targetUsername/log accepted free-form `status` and
`layer` values and wrote them directly to followLog without validation.
Both fields feed analytics counters (totalFollows) and the
follower-state dashboard via `status: 'success'` queries, so an
authenticated user could fabricate successful follow events, inflate
engagement metrics, and manipulate the dashboard.
Fix:
- Add `followLogSchema` (Zod) in validations/follow.validation.ts with
strict enum allowlists:
status → 'success' | 'failed' | 'pending'
layer → 'foreground' | 'background'
- Validate request body with safeParse before any database write;
invalid payloads return 400 without touching followLog.create()
- Remove unsafe free-form defaults ('success' / 'webview') that
silently accepted omitted fields
- Response body on validation failure contains only { error } —
no Zod internals, paths, or stack traces are exposed
Layer 1 (API follow) writes status/layer internally and is unaffected.
Tests: 22 cases covering all valid enum combinations, all rejection
paths, DB-not-called guarantee on failure, correct payload written to
DB, and opaque error responses.
Closes Dev-Card#301
Ridanshi
force-pushed
the
fix/follow-log-analytics-poisoning
branch
from
0988d25 to
4f14f98
Compare
Contributor
Author
|
Cleaned the branch and removed the unrelated event changes from PR #337. The PR now contains only the follow log validation changes related to issue #301:
I had accidentally branched from the events work earlier, that unrelated commit has now been removed and the branch was safely force-pushed with Latest commit: |
Harxhit
approved these changes
May 27, 2026
Collaborator
Harxhit
left a comment
Harxhit
left a comment
There was a problem hiding this comment.
Changes are spefically to follow route eslint proofs and tests proofs are provided.
Harxhit
added
level:advanced
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
2 participants
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.
Closes #301
Summary
Fixes an analytics integrity flaw where authenticated users could submit arbitrary
statusandlayervalues to:POST /:platform/:targetUsername/logThe endpoint previously persisted attacker-controlled values directly into
followLogwithout validation.These fields are later consumed by analytics and follower-state logic, allowing fabricated follow activity and poisoned engagement metrics.
Problem
The route accepted free-form values for:
statuslayerand wrote them directly into persistence: