So I take it your code could handle a 1GB blog post safely without giving you an error about exceeding post_max_size or something similar?
That would be a bug.
Small code != bug free code.
> To prevent users from causing server timeouts, the default maximum upload size in WordPress typically ranges from 4 MB to 128 MB.
> Google will index up to 2.5MB of an HTML file.
But I read lynx has no issues with giant html files.
If I had a need for it I could use ftp. If the need is frequent I could upload chunks of textarea at a time. Until then I'm going to consider it undesirable.
If your code is as small as I'm imagining it, then it's not handling a lot of error cases, and doesn't cover any edge cases. That's where bugs lurk.
Auth is a cookie, session, ip and password check.
It builds a html document from 3 strings.
It writes the document to the file system and to the backup folder.
Which part do you imagine to be the most error prone? I'm having a hard time imagining doing fwrite wrong. I mean? lol?
For the malicious actor to gain access they would need to guess the url, guess what the post vars are called, obtain a cookie (set by a deleted php file) and guess the password.
Then one would be able to edit or create a html document. I suppose inserting some malicious js into the newest post shortly after its created could escape my attention. It could take some time for me to notice it. When I do notice it ill restore the documents from a backup. It wouldn't take a DBA.
My rss reader wouldn't like <script> onload onclick etc. I think I would notice my own feed getting flagged.
I'm sure someone could hack the blog but its not worth the effort.