Although this is an old post, the high level concept is still relevant today. Is what you are doing safe? Not really, but that is subjective and to answer critically would require some specific code examples to show how you are capturing the input, formatting it and saving it to file, where and how that file is stored and the later accessed and how the content is rendered.
When talking about security in a web application context there are a number of fundamental contexts or attack vectors that we might want to consider, not all apply to all scenarios, or even this scenario but the obvious ones that we watch out for in relation to sanitizing inputs in a POST against a data store are:
NOTE: This is not supposed to be an exhaustive list, instead it is to demonstrate that the threat is real and more complicated than OP's naive assumption. These are some results from searching the web on this topic:
Injection Attacks
Injection attacks are not simply restricted to SQL, in fact most modern injection attacks involve input of scripts or commands that will be executed or will affect the rendering of the data, not necessarily the storage mechanism. So while your solution does not use a SQL based store, it does nothing to prevent users from injecting javascript commandlets that might be executed when your data is rendered to the screen.
Even if an attacker is not overly malicious, values could be inserted into the input fields that would conflict with standard file format parsers, perhaps only to prevent the file from loading. There is a particular brute force process called Fuzzing where an attacker deliberately tries to overload input fields to cause an exception, by analysing the type or length of the data and any responses from the server at the point of failure, an attacker might identify vulnerabilities.
This is an interesting post on a common vulnerability in writing to and reading from XML files: An XML file can break?
Confidentiality
Without password-protecting your app, any user could assign tasks to any other user, or could re-assign the users or complete tasks on behalf of other users. In your contrived example, this might not be a concern, but the idea that someone might "guess" a user Id or deliberately obtain or brute force ids, for the purpose of being a pest or a denial of service attack is not something to ignore. If someone decided to write a script to send blank entries for all users starting from Id=1 right through to Id=10000000 then users may stop using the site because their ToDo's are gone, or they keep getting bogus data. If the script is active enough, something like that could easily degrade the performance to a level where the site grinds to a halt, even if their plan was not DOS, the end result would be the same.
Even if you are not using integer keys, brute force attacks like this are just as easy with other data types.
Data Integrity / Corruption
Attacks against data Integrity or Validity might not directly affect the operation of a ToDo app, in other styles of applications it can cause failure when expectations are not met or may provide access to other records that they should not have access to.
If there are relationships between files, such as grouping or assignment of tasks to other users then if the data input is not validated against known types or values, then a careless or malicious input might prevent data from being displayed, or might allow a user to associate their data with other resources that they should not have access to, in this way they may gain access to those other records via association.
What is the actual Risk of attack?
Most attacks against web sites are conducted by bots or automated scripts that are simply crawling the web looking for vulnerabilities. Do not think that due to anonymity of your brand or the fact that you do not openly advertise your site that you are protected by obscurity and therefore at low risk to a hacker specifically targeting your site.
The reality is that often when we do get hacked, we are not that special at all and haven't done anything specifically to attack their attention other than leaving the door wide open for the attack.
How Authentication Can Help
The obvious benefit that comes from Authentication is that you can scope the data or resources based on the current user. Via Authorization or Filtering logic you can prevent a user from accessing confidential (or any) data generated by other users.
However, having Authentication in place can provide you a simple mechanism to control or prevent some types of attacks. Once you have identified a credential that is being involved in an attack, you can revoke any rights or flat out block that credential from being used, in many cases without affecting access by other authenticated credentials.
