The 14 attack scenarios

Technical statement Evidence: test As of: 28.10.2026

What is this about?

An attack scenario asks: what happens if someone takes over this account or tries this route? Each of the 14 scenarios has automated tests whose result is in the monthly report. Some scenarios have documented limits, which we state openly.

Protection goal

We do not only want to know that individual safeguards work, but also what happens when someone deliberately tries to get around them. The scenarios turn typical attacks into questions we can check.

How it works

In the source code, each scenario is assigned to a group of test classes. The monthly report is produced from a real test run: a scenario only counts as passed if its tests appear in the current run and pass. If a test is missing or fails, the scenario is not carried over from an earlier report but reported as a regression.

Measures

The table shows what is checked and whether the report names a limit for a scenario (as of October 2026). We take the names of the scenarios from the report.

Scenario	What is checked	Note in the report
Compromised User	A signed-in user tries to access data from other projects.	–
Cross-Tenant IDOR	A user swaps identifiers in requests to reach other people’s projects.	–
Compromised Co-Author	A co-author account is taken over: does access reach only as far as granted, and are blocked accounts shut out on every request?	–
Compromised Editor	An editing access is taken over: does it stay limited to the shared book and its level?	–
Compromised Admin	A user management admin account is taken over: can it reach book contents?	documented limit
Session Hijacking	A stolen session is used from another device.	documented limit
Race Conditions	Simultaneous requests try to outrun checks, for example when saving or claiming a chapter.	–
API Manipulation	Requests with additional fields try to set values a user must not set.	–
Vault Policy Bypass	Someone tries to use the key management outside its access rules.	–
Authenticated Scraping	A signed-in user tries to read out data in bulk.	–
Branch/Merge Manipulation	Someone tries to get around the rules when branching and merging timelines.	–
Permission Escalation	A guest or co-author tries to obtain higher permissions.	–
Compromised Symfony Runtime	The application process runs under foreign control: what does the key management protect?	documented limit
Deployment Integrity	Code on the server is changed afterwards or the delivery is tampered with.	known remaining measure

What we do not promise

The 14 scenarios are a selection and not a closed list of possible attacks.
“Compromised Admin”: That application admins do not see book contents does not hold against people with root access to the server.
“Session Hijacking”: The detection of taken-over sessions has documented limits and does not recognize every takeover. Details are in the report.
“Compromised Symfony Runtime”: An actively compromised application process can reach data that is in memory at runtime.
“Deployment Integrity”: The detection of later code changes exists and is tested. Further hardening of the delivery is still open; details are in the report.

How we check this

The assignment of scenarios to test classes is fixed in the source code, and a test makes sure every named test class exists. The results are in the report each month. The evidence tests below show which tests serve which scenario.

Evidence tests

Test	What the test proves
`AuthorizationCoverageTest`	Compromised User, Compromised Admin: Every route of the application has an explicit access decision.
`IdSubstitutionCrossTenantTest`	Compromised User, Cross-Tenant IDOR: Requests with swapped identifiers do not reach data from other projects.
`TenantFilterCoverageTest`	Compromised Co-Author: Every table that belongs to a project is automatically narrowed to the allowed projects.
`VoterUserStatusGateCoverageTest`	Compromised Co-Author: Every permission check takes the current account status into account.
`GuestEditorialAccessTest`	Compromised Editor: The editing access reaches only as far as intended.
`EditorialGrantInvitationTest`	Compromised Editor: Only the owner can grant editing access, a co-author cannot; books from other projects are rejected.
`EncryptionCoverageTest`	Compromised Admin: Text fields such as chapter content are mapped as encrypted, not as plain text.
`UserLegalDataVisibilityVoterTest`	Compromised Admin: Even a user management admin does not see the legal data of another account.
`SessionHijackDetectionTest`	Session Hijacking: A session suddenly used from a different browser is ended and the account is notified.
`ChapterContentSaveRaceConditionTest`	Race Conditions: Saving the same chapter at the same time does not overwrite anything silently.
`ChapterClaimRaceConditionTest`	Race Conditions: If two users claim the same free chapter at the same time, only one wins.
`MassAssignmentProtectionTest`	API Manipulation: A request cannot overwrite system fields such as the owner of a project.
`VaultLeastPrivilegePolicyTest`	Vault Policy Bypass, Compromised Symfony Runtime: In the key management the application has only the permissions it needs.
`VaultFailClosedTest`	Compromised Symfony Runtime: If the key management is unreachable, requests are rejected instead of carrying on.
`GenericAuthenticatedReadRateLimitTest`	Authenticated Scraping: Too many read requests from a signed-in account are rejected.
`TimelineBranchTest`	Branch/Merge Manipulation: A branched timeline leaves the main line unchanged, chapters of others are rejected.
`TimelineBranchMergeTest`	Branch/Merge Manipulation: Merging requires edit permission and reports a conflict if the main line has changed since branching.
`AccessGrantEditorialPermissionEscalationTest`	Permission Escalation: A co-author cannot raise a share to editing rights, neither directly nor by changing it.
`IntegrityVerifyCommandTest`	Deployment Integrity: Changed, new and removed files are detected.

Read the report

Change history

28.10.2026: First version.