dataurl := "data:" [ mediatype ] [ ";base64" ] "," data
mediatype := [ type "/" subtype ] *( ";" parameter )
data := *urlchar
parameter := attribute "=" value
where "urlchar" is imported from [RFC2396], and "type", "subtype", "attribute" and "value" are the corresponding tokens from [RFC2045], represented using URL escaped encoding of [RFC2396] as necessary.
Attribute values in [RFC2045] are allowed to be either represented as tokens or as quoted strings. However, within a "data" URL, the "quoted-string" representation would be awkward, since the quote mark is itself not a valid urlchar. For this reason, parameter values should use the URL Escaped encoding instead of quoted string if the parameter values contain any "tspecial".
The ";base64" extension is distinguishable from a content-type parameter by the fact that it doesn't have a following "=" sign.
I used this solution for creating npm package valid-data-url and got an email that explained that my package is vulnerable for ReDoS exploit. I checked this one - it also does. I found a tool that helps to validate the regex for such exploits. Take a look: https://github.com/NicolaasWeideman/RegexStaticAnalysis
Back to the initial solution on the top, I recommend
\s*
from the beginning and from the end of the regex!!s.trim().match(isDataURL.regex);
to support existing functionality and fix exploit issue in the same timeHope this helps