fix(security): separate booking and check-in tokens

This commit is contained in:
bisco
2026-04-29 21:49:21 +02:00
parent 5cad1871e7
commit 13a05f6d0d
10 changed files with 214 additions and 64 deletions

View File

@@ -36,6 +36,9 @@ Rules:
- do not encode personal data in tokens;
- store token hashes when practical;
- treat raw tokens as secrets;
- keep confirmation tokens and check-in tokens separate by purpose;
- allow confirmation tokens only for reservation confirmation;
- allow check-in tokens only for QR retrieval and check-in validation;
- mark one-time confirmation tokens as used after successful confirmation;
- expire confirmation tokens after a reasonable period;
- keep QR tokens valid only for the intended performance and check-in period where practical.
@@ -165,7 +168,7 @@ Do not log:
Initial residual risks:
- synchronous email can make booking responses depend on SMTP availability;
- synchronous email after commit can still add latency to booking requests even though it no longer runs inside the reservation transaction;
- QR codes can be copied, so duplicate check-in prevention must be reliable;
- staff account compromise would expose admin and check-in functionality;
- retention and deletion rules for personal data still need a project policy.