The Secret to Secure Anonymous Surveys: Our Hybrid Security Solution

For any organisation seeking to collect honest feedback from its stakeholders, ensuring full anonymity is highly important. Yet, achieving robust security without compromising user experience and anonymity is still a huge challenge! Traditional security methods often force the difficult choice between one or the other; results, and security. With this in mind, we’re excited to share our latest research, “Innovative Authentication for Anonymous Surveys: A Cryptographic Token and Behaviour-Based Rate-Limiting Approach”.

This research explores the critical challenge of secure survey submissions – where traditional authentication simply isn’t an option. We introduce a hybrid approach to protecting the anonymous survey system from abuse, while also maintaining the system’s usability. This is without any form of user identification or persistent tracking.

This approach goes far beyond a common protective security policy framework; we’re trying to push the boundaries of what is possible in a zero-trust application context – let’s dive a bit deeper.

How do we secure survey submissions without tracking respondents?

When running a survey where anonymity is critical, such as for sensitive feedback, the main challenge is how to stop “bad” robots from inundating the survey with fake responses or attackers from trying to downgrade survey performance. This is tricky because you can’t ask respondents to login, or even know who they are.

Here we’ve come up with a clever way to do this, using two main tricks:

1. Secret and Temporary Passes (i.e. Stateless Cryptographic Session Tokens)

Think of it like this: every time someone opens your survey link, our system quietly hands them a secret pass. This isn’t a pass with their name on it, or anything that could identify them. It’s more like a unique and invisible stamp of approval that says, “This survey access is legit!”.

This pass is clever because it’s built using a kind of digital fingerprinting (i.e. the “stateless  cryptographic” part) that makes it impossible for anyone to fake or reuse it. It also has a very short expiry period, so it’s only good for a quick visit. Once the respondents have submitted their survey, that pass is gone, and nothing about it is stored on the server side. This is how we guarantee full anonymity – no one can trace it back to the respondents. 

2. Bahaviour-Based Security Guards (i.e. Throttling Layer)

Instead of setting up rigid rate limits, we implemented a behaviour-based throttling layer for our system to observe how people are interacting with the survey.

This looks out for unusual behaviour, such as an individual person trying to submit hundreds of responses in a few seconds, or suspicious patterns in how often they submit, how quickly they do it, right down to the time between their responses. If our security spots anything odd – not who is doing it, but what it is they’re doing – it will slow down the rate at which those unusual requests are able to come in. What’s more, our system won’t completely block them – therefore, legitimate users on shared Wi-Fi won’t be inadvertently blocked.

This includes dynamic rate adaptation, from which the system automatically adjusts how many survey responses it will accept based on recent activity. This helps us differentiate between genuine responses coming in quickly (like running the survey during an event on a shared Wi-Fi) and a malicious flood of submissions. Best of all, it keeps the experience smooth for everyone who’s legitimately taking the survey.

Why don’t standard security methods work?

Before developing our custom solution, we evaluated some common security strategies, but each fell short in crucial areas:

• Session-based or token-based authentication issues a “session” or “token” after a user logs in. This token acts as a digital ID that the system uses to remember who you are and what you’re allowed to do. This is the biggest clash. The entire purpose of this method is to identify and track a user’s activity, whereas for anonymous surveys, we explicitly do not want to identify or track any user.
• IP-based rate limiting simply counts how many requests come from a single IP address within a certain timeframe. If too many requests come from one IP, it gets temporarily blocked. This will often block legitimate users sharing networks (like in offices or schools).
• CAPTCHA systems present puzzles that are easy for human but hard for robots. If you solve it, you’re proven to be human. This will interrupt the respondents’ flow of answering the questions and can be frustrating. For an anonymous survey, we want it to be as easy and seamless as possible to encourage participation.

Simply put, conventional methods did not strike the balance between security, user experience, and full anonymity. Our approach, on the other hand, addresses this critical gap, especially offering robust protection without interrupting the user experience.

Why should this matter to leaders?

For organisations relying on anonymous feedback, this approach is important to show the possibility of building highly secure systems without sacrificing the user experience and privacy. This allows for:

• More trustworthy data collection: We can strengthen the overall information security framework by reducing spam and malicious submissions, which improves the integrity of the survey data collected.
• Boost respondents’ confidence: Knowing their anonymity is genuinely protected encourages more honest and widespread participation.
• Improved system reliability: This system can perform well even when many people are using it at once, so the surveys are always available and collecting information reliably. 

This application of cryptographic tokens and behaviour-based throttling offers valuable insights for anyone designing systems that require both robust security and uncompromised anonymity.

If you’re tackling similar challenges in your web application or survey development, we’d love to hear from you!

---