One way to execute possibly unsafe code is with Safe.
True, but I normally don't mention Safe because I think it's a little too easy to misuse. It requires a good amount of knowledge of the Perl internals, one must know not only which opcodes need to be allowed, but exactly what each one of them does; allowing only one too many can theoretically open a door for attackers. Plus, opcodes do sometimes change (rarely, but still), so that might have to be taken into account. Finally, the module currently appears unmaintained, and IIRC, has had some security-related bugs in the past. If used properly, Safe can make eval safer, but not "safe". That's why if there's any doubt, I'd recommend to not eval at all.
That's why if there's any doubt, I'd recommend to not eval at all.
Correct. And that also excludes do FILE, require, and use. See Re^4: Using guards for script execution? for details.
The sane way of handling foreign data is to use a non-executable format like JSON. Perl has several JSON parsers / generators at CPAN.
YAML can contain executable code (but I think you have to explicitly enable that). XML does not contain executable code, but it may contain references to local and network resources (https://en.wikipedia.org/wiki/XML_external_entity_attack) and it may contain DoS attacks (https://en.wikipedia.org/wiki/Billion_laughs). YAML is also vulnerable to the latter attack. CSV and INI file formats may appear simple, but both are essentially underspecified and thus have some "interesting" edge cases. Text::CSV_XS can handle most, if not all CSV files, because it has support for most, if not all of the edge cases.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)