generated from bisco/codex-bootstrap
fix(security): separate booking and check-in tokens
This commit is contained in:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user