I think you have answered your own question. If your program will behave badly if the configuration files are corrupted, then it seems that you must provide protection against such corruption. (In fact, IMO, every program should defend itself against bad input from all external sources.)

You could start by answering a few questions like these:

• How important is it that your program behave well? Is it a matter of life and death (like an airplane control system or some sort of medical instrument), or something less critical (like a game program)?
• Do you think your users will actively try to change the configuration files on purpose, or do you think it would be just an accident?
• Etc.

Thinking about things like that will help you decide how much effort you should apply in trying to make the protection mechanism foolproof.

I just got done with a project that had a similar requirement. As in your case, my configuration files are plain text files that the users might mess with. I wound up adding a checksum record at the end that simply contains the sum of all the preceding characters in the file. A malicious attacker could easily figure out the scheme and build a corrupted file himself with a valid checksum. However, in my case there is no motivation for anyone to do that, so all I'm trying to do is defend my program against configuration files that have been accidentally changed or misnamed.

-- Russ