[Enhancement] Improve docs feedback system to reduce noise in case of spam and have an easier way to deal with it

[animeshk923]

During a regular GH notification check, I was presented with a lot of bot discussion topic notification.

It seemed unusual so I asked on AsyncAPI's slack channel. @princerajpoot20 told that:
"It seems like someone is trying to do a sort of brute-force sql injection. In order to avoid this, we will need to modify how we are capturing this feedback, as currently we need to close them one by one manually."

I was asked to put this up for a discussion so I'm creating this issue in this repository (i hope it's the correct repo 😅)

---

Slack Reference: https://asyncapi.slack.com/archives/C02FK3YDPCL/p1774350210089069?thread_ts=1774349721.442669&cid=C02FK3YDPCL
cc: @anshgoyalevil @derberg @Shurtu-gal

[princerajpoot20]

I checked all the feedback, and it’s all spam. It looks like someone attempted a brute-force SQL injection attack.

Now, coming to the solution:

This issue is coming from the feedback section on our website, under the docs section. At the end of every document, we have a feedback form, and we capture that feedback as discussions on GitHub.

The problem is that if someone exploits this with a brute-force attack, we get flooded with multiple discussions, making them difficult to process. We then have to close them manually, one by one.

To resolve this, we need to change how we capture this feedback. We cannot continue creating a new discussion for every piece of feedback, as it can easily get flooded.

We need a more centralized storage approach.

For example, we could use a single discussion thread, or even better, store the data in something like an Excel sheet where all entries are appended, or choose another better storage solution.

[sammy200-ui]

@princerajpoot20 @animeshk923 i was also looking in this from that day ,they are all common SQL injection probes, like for example PG_SLEEP(15) for PostgreSQL and DBMS_PIPE.RECEIVE_MESSAGE for Oracle, the the good news is that the flow goes from the form straight to the GitHub GraphQL API via a Netlify function, so those SQL payloads didn't do any actual damage except those spams.

the problem seems to be in endpoint at /.netlify/functions/github_discussions code, currently it has some problem and i will post those down

• there is no rate limiting, anyone can hit it as many times as they want
• a concept of graphql called string interpolation , the current code has title and feedback values from the user and they are dropped directly into the mutation string using template literals, the @octokit/graphql library itself warns against doing this ref because it makes the code vulnerable to query injection attacks.

Also on the frontend side the feedback component also does not do any validation before sending the request.

Your idea about centralizing the storage is good for reducing noise long-term, but even with a centralized approach we would still need the sanitization and rate limiting, otherwise the same thing will happen to whatever storage we switch to.

[princerajpoot20]

@sammy200-ui
For the rate-limiting part, since this is an unprotected (unauthenticated) route, we would need to rely on a service like Cloudflare Turnstile. It helps protect against DDoS (Distributed Denial of Service) attacks by verifying requests using multiple factors, patterns, and signals.

If you’re suggesting adding simple rate limiting on our end, it doesn’t make much sense to me. On an unauthenticated route, what basis would we use? For example, if we limit it to 50 requests per minute, what happens after that? Genuine users might get blocked. If we do it based on IP, that can also be bypassed by changing the IP.

So, to properly prevent this, we would need something like a CAPTCHA or a better service like Cloudflare Turnstile.

Regarding your second point, yes, it’s a good idea to perform a sanity check. Do we have any library or mechanism to handle this? I’m not aware of one or can’t recall at the moment. Could you check how we can implement this?

[princerajpoot20]

For now, the main problem we are facing is the noise in the GitHub discussions. Our first priority should be to reduce that noise by finding a way to avoid creating multiple discussions in any possible scenario.

Think of it this way: forget about spam and attacks for a moment. Let’s say we have 1,000 genuine user feedbacks. In this case, all rate limiting and sanity checks would pass, we would end up with 1,000 open discussions on GitHub. Processing all that feedback would be very difficult.

We need a way to view all the feedback quickly in one place. This makes it easier to identify common feedback coming from multiple users. Such analysis is only possible if we have consolidated feedback in a single location.

[sammy200-ui]

@princerajpoot20 Yeah totally, Turnstile/CAPTCHA should be the primary layer for bot protection, IP rate limiting alone just isn't going to cut it on an unauthenticated route.

And honestly the volume thing being a separate problem from spam is a good call. Even if nobody's attacking the form, decent traffic would still bury us in individual discussions. So yeah, fixing the architecture first makes the most sense.

A few ways i think we could consolidate:

-Single discussion thread per doc page, append each feedback as a comment instead of creating a new discussion. That way everything for one page is in one place and you can see patterns at a glance.
-Google Sheet / Airtable, store feedback in a spreadsheet via their API. Easy to filter, sort, and spot trends across all pages.
-Simple JSON/CSV in a repo commit feedback to a data file via the GitHub API. Low-tech but keeps everything within the GitHub ecosystem.
Each of these naturally reduces the noise because you're not creating a new discussion per submission.

Also i took a look at the sanity check i mentioned early - we don't actually need a separate library. The @octokit/graphql library already supports passing GraphQL variables as a separate object ref instead of string interpolation (which their docs specifically warn against). If we end up changing the backend to write to a sheet or a single discussion, the exact fix would look different, but the principle is the same, never interpolate raw user input directly into queries.

cc : @animeshk923

[animeshk923]

For the feedback, how about we display existing ones on the page below input box by lazy loading them? Would it help reduce in duplicate feedback if a user sees that they already exist?

For feedback collection and viewing them in a "thread" manner, we can use disqus (paid) or it's alternatives.
Example screenshot (disqus):

And, yes, as metioned by @princerajpoot20, CloudFlare Turnstile is necessary to prevent spams.

[sammy200-ui]

@princerajpoot20 @animeshk923 those spams seems to be happening again, might need to resolve this soon

[animeshk923]

@princerajpoot20 @animeshk923 those spams seems to be happening again, might need to resolve this soon

yes, got a wave again around 14 hours ago from now

[sammy200-ui]

@princerajpoot20 Yeah totally, Turnstile/CAPTCHA should be the primary layer for bot protection, IP rate limiting alone just isn't going to cut it on an unauthenticated route.

And honestly the volume thing being a separate problem from spam is a good call. Even if nobody's attacking the form, decent traffic would still bury us in individual discussions. So yeah, fixing the architecture first makes the most sense.

A few ways i think we could consolidate:

-Single discussion thread per doc page, append each feedback as a comment instead of creating a new discussion. That way everything for one page is in one place and you can see patterns at a glance. -Google Sheet / Airtable, store feedback in a spreadsheet via their API. Easy to filter, sort, and spot trends across all pages. -Simple JSON/CSV in a repo commit feedback to a data file via the GitHub API. Low-tech but keeps everything within the GitHub ecosystem. Each of these naturally reduces the noise because you're not creating a new discussion per submission.

Also i took a look at the sanity check i mentioned early - we don't actually need a separate library. The @octokit/graphql library already supports passing GraphQL variables as a separate object ref instead of string interpolation (which their docs specifically warn against). If we end up changing the backend to write to a sheet or a single discussion, the exact fix would look different, but the principle is the same, never interpolate raw user input directly into queries.

cc : @animeshk923

might need to scrap the idea of using JSON or CSV, now i am thinking about this, it would cause other issues like conflicts with multiple users and just overall not being a very reliable approach

[princerajpoot20]

-Single discussion thread per doc page, append each feedback as a comment instead of creating a new discussion. That way everything for one page is in one place and you can see patterns at a glance.

@sammy200-ui you forgot about the main problem. in this, you have to manually delete the spam comments one by one

For the feedback, how about we display existing ones on the page below input box by lazy loading them? Would it help reduce in duplicate feedback if a user sees that they already exist?

@animeshk923 You also forgot the main issue. if we display the feedback directly on the website, don't you think it will get flooded on the website in case of spam, which makes that feedback section useless

also, what if someone enters abusive/inappropriate content in the feedback? it will be displayed directly on our website, which should not be there.

For feedback collection and viewing them in a "thread" manner, we can use disqus (paid) or it's alternatives.
Example screenshot (disqus):

@animeshk923 Again, if it is thread-based, as shown in the image, I don't think it will support bulk operations like selecting multiple entries in one go and deleting all of them. For the one you mentioned, how will you handle the spam case with this?

[princerajpoot20]

Moving this issue to the website repo, as this requires changes there