Kudos on using taint, strict, warnings, and so on. I also like that you are approaching security levels as a relative value, not an absolute one.

... here comes the "but" ...

Security is not achieved by one single component, but by a sum of the component parts. The system should be evaluated as a whole. Also, without knowing what this is a part of, it is very difficult to assess the level of security. If I were to rate this application on just its own merits, I would give it below average marks, but not the worst I have seen. Not something I would allow on my systems, but better than Matt's Script Archive.

I have a few specific (not complete) critiques. Do not take this as a complete list.

• I am not convinced that your untainting code does what it is supposed to without knowing your data requirements. The cost of the effort of security needs to be compared against the value of the data, loss of data¹, loss of reputation, and so on.
• fatalsToBrowser should not be set on a public-facing application. The errors should be logged and reported to the production maintenance group, and the user should get a generic "Oops" message indicating that an error occurred and what they need to do (possibly nothing). I understand why you did it (so die would send stuff to the user directly), but errors that are outside of what you test for will dump information to an attacker that should not be given.
• You don't check the status of your flock calls, so you still have a race condition. Since the resolution on your filename is 1 second, you only need two clients to connect at the same time with sufficiently large parameter lists to be able to see this. In production, this is not a matter of if, but when this will happen.
• Your "antiInjection" routine appears to be rejecting SQL keywords. Are you planning on hooking this up to a database? There are a plethora of issues when hooking up to a database.
• Not really security, but makes me ask if appropriate attention was given elsewhere (including security): your HTML will not validate (nesting on the END OF DOCUMENT line, stuff outside of html container, etc.
• Additionally, by using die to send error messages directly to your browser, you are bypassing the output from footer. There are ways to use die, but it would involve using eval in tandem with it in a try/catch type construct.
• Why chmod 0666 the output file? This relates to my comment about the entire system. Can you trust that the data is the same as when your application saved it? A different approach could modify the file after your application was finished with it.
• Predictable file names. Unless you have a reason to have predictable file names, don't use them from your web server. Bad Guy (the evil brother of Good Guy, not to be confused with the homebound Family Guy), given an alternate means of access to the storage area, can create a denial of service attack by filling your file system with files matching the name pattern for the foreseeable future, set them to mode 000, and leave them there. The clients will not be able to open the file.

1 - See The theft of business innovation: an ACM-BCS roundtable on threats to global competitiveness for a view of how "low value" targets are now being attacked.