I attacked DayBlock: the security audit, written up for everyone

DayBlock makes a big promise: your entries, notes and journal are encrypted on your device, and the server only sees gibberish. A promise like that is worthless if nobody checks it. So in October 2026 I put DayBlock through a complete internal security audit – touched every door once, rattled every lock once. Here is what I checked, what I found and what I improved right away. The full report is available as a PDF, written for everyone, not just for experts.

Why an audit – and why in public

Security is not an add-on for DayBlock; it is the reason DayBlock is built the way it is. A day planner knows when you see the doctor and how you felt on a Tuesday evening. In the threat model I already laid out how DayBlock is built and where the limits are. An audit is the next step: instead of describing how things should be, I check whether they really are.

And why in public? For the same reason as the threat model: good security does not depend on nobody knowing how it is built. If I publish the results, you can read them, compare them with other services – and hold me to them. One rule always applies: only what is already fixed gets published. If I found an open vulnerability, I would close it first and write about it afterwards.

What I checked

The audit went once through everything between your browser and the database:

• Sign-in and account: the sign-in method where your password never leaves your device, sessions and their cookies, recovery with the 24 words, signing out and deleting the account.
• Encryption: the keys created on your device, the wrapping of the main key, the encryption of every record and the question of whether the server really never sees plain text.
• Sync between devices: whether anything can be injected or swapped while the encrypted envelopes travel back and forth.
• Groups and sharing: private groups whose key only lives in the invitation link, public groups and the report function.
• Calendar subscriptions: when DayBlock fetches an external calendar for you, that must not become a back door into the internal network. I played through exactly this class of attack – a server that can be sent to arbitrary addresses.
• Magazine and editing: whether articles can smuggle foreign code into the page.
• The rest: emails, limits against password guessing, the browser's security headers, the app's local storage and all libraries used (automatic check for known vulnerabilities).

To be clear and honest: this was an internal audit – I ran it myself, systematically and with the help of AI analysis tools. It does not replace the independent external review by professionals. That one remains mandatory before DayBlock opens to everyone, and its report will be published too.

The result in one sentence

I found no critical vulnerability – no way to get at encrypted content, passwords or other people's accounts. What I did find were three places where DayBlock could be more careful than it was. I improved all three while the audit was still running.

Three things I improved immediately

1. The browser now insists on an encrypted connection, permanently. DayBlock was always reachable only over an encrypted connection. What is new is a header that makes your browser remember this for a whole year: it will not even try to open an unencrypted connection any more – even if someone on the same Wi-Fi tried to redirect it there.
2. Sender information gets less trust. Requests reach DayBlock through an upstream relay that tells the server which address a request comes from. The server now trusts this information exactly one hop far. Before, in an unlucky setup, someone could have attached a made-up sender address and tricked the limits that slow down password guessing. The relay in use discards such made-up information itself, but security should not hang on a single point.
3. A side service of the test environment gets the strict headers too. A small service that only exists in the internal test environment ran without the security headers that the website and app have had for a long time. It was no risk to user data – the test environment only holds toy data – but consistency is the better habit here.

What withstood the test

An audit does not just find weaknesses; it also confirms strengths. These points held up:

• Your password stays with you. Even under close inspection: it never leaves your device; the server cannot see it or write it down.
• Encrypted records cannot be swapped. Every record is bound to its own identifier. Anyone reshuffling envelopes in the database only produces error messages, never wrong entries.
• The calendar fetch is no back door. DayBlock checks on every fetch that the target address is public – after redirects too, and even when an attacker tries to trick the name lookup.
• Articles cannot inject code. Editorial texts are defused character by character before they become a web page; links are limited to harmless forms.
• The database takes no commands from outside. All database access is built so that input always stays data and can never become a command.
• Foreign pages cannot act in your name. Modifying requests need a marker that only the real app can set, and your session never travels along to other sites.
• The libraries are clean. The automatic check of all libraries in use reports no known vulnerability.

Honest limits: what the audit does not change

A few things stay the way the threat model describes them – an audit does not magic them away:

• The server delivers the code. The fundamental problem of every encrypted web app: whoever controls the server could deliver altered code. Planned against this: verifiable builds with published checksums, and later apps with built-in code.
• Two-factor sign-in is still missing. Until then, a short or reused password remains the biggest risk – and only you can keep it small.
• Who is registered can be guessed. As with almost every service, trying to create an account with someone else's email address reveals whether that account already exists. Recovery and resending the confirmation deliberately answer neutrally instead.
• The external review is still to come. This audit was mine. Before the public launch, external professionals will review DayBlock – and their report will appear just as openly as this one.

The report as a PDF

I wrote the full report up as a PDF – deliberately so that anyone can understand it: what was checked, what was found, what was improved and what remains open. You can download it, pass it on and hold me to it:

Security report October 2026 (PDF, English)
Sicherheitsbericht Oktober 2026 (PDF, German)

Every future audit gets a new, dated report; the old ones stay available. That way you can follow over time how DayBlock becomes more secure.

Found a vulnerability?

Then please write to hallo@dayblock.de with the subject “Security”. Describe what you found and how it can be reproduced. I will answer, fix the issue as fast as I can – and will gladly credit you by name afterwards if you want that. Please only test with your own account and do not access other people's data.