"Anyone can generate a QR code. Designing one that actually prevents misuse is the hard part."
When people hear "QR-based attendance," the first question is usually:
"Can't someone just take a photo of the QR code and send it to their friend?"
The answer is: yes, if the system is designed poorly.
That question became one of the biggest engineering challenges while building my attendance platform.
Instead of thinking about QR codes as images, I started thinking about them as temporary authentication tokens.
The Problem
Most QR attendance systems work like this:
- Teacher generates a QR code.
- Students scan it.
- Attendance is marked.
Simple.
Unfortunately, it's also vulnerable.
A student can:
- Photograph the QR code.
- Send it through WhatsApp.
- Another student scans it from somewhere else.
- Attendance gets recorded.
The QR code itself becomes the vulnerability.
Rethinking the QR Code
Instead of creating a QR code that simply points to an attendance page, I designed it to behave more like a short-lived authentication token.
Every QR code is generated dynamically and remains valid only for a limited period (in my implementation, I set this to 11 seconds).
Once it expires, the system rejects it.
This dramatically reduces the opportunity for someone to reuse an older QR code.
Authentication Beyond the QR
Scanning the QR code alone isn't enough.
The backend performs additional validation before marking attendance.
Rather than trusting the client, the server becomes the source of truth.
This reduces opportunities for client-side manipulation and keeps the attendance workflow under server control.
Designing for the Real World
One challenge I encountered was balancing security with usability.
If the QR expires too quickly, students may struggle to scan it in time.
If it stays active for too long, it becomes easier to misuse.
Finding the right balance required thinking about actual classroom conditions rather than only technical implementation.
Lessons Learned
One lesson stood out throughout this project:
Security isn't usually one big feature.
It's the result of multiple smaller decisions working together.
A dynamic QR code helps.
Server-side validation helps.
Short-lived sessions help.
Each layer reduces risk.
What's Next?
This article only covers one piece of the system.
In future posts, I'll explore:
- Backend architecture
- Firestore data modeling
- Authentication flow
- Scaling the platform
- Engineering decisions behind the project
Building software has taught me that writing code is only part of engineering.
Designing systems that continue to work under real-world conditions is where the interesting problems begin. In this project, I used libraries like qrcode on the backend to generate dynamic QR codes and html5-qrcode on the frontend to scan and verify them efficiently, while SHA-256 hashing was used on the backend to securely generate and validate the QR token payloads.
⭐ GitHub: https://github.com/siddarthpatelkama
💼 LinkedIn: https://www.linkedin.com/in/siddarthpatelkama
Top comments (0)