We might actually just use regular expressions and some other algorithms without having to rely on a specific language, hopefully that's what you need.

By declaring that the object key is inside [a-zA-Z0-9_-] we need to parse the value somehow.

Value Model

So we can break it down into categories and see what we come across (they may be slightly simplified for clarity):

1. '.*' (String surrounded by apostrophes; greedy)
2. ".*" (String enclosed in double quotes; greedy)
3. [ -]?\d (\.\d )?(%|[A-z] )? (integer and decimal, optional percentage or with unit)
4. #[0-9A-f]{3,6}(color)
5. [A-z0-9_-] (keywords, named colors, "ease in", etc.)
6. ([\w-] )\([^)] \) (functions similar to url(), calc()> etc. )

First filter

I can imagine you could do some filtering before trying to identify these patterns. Maybe we trim the value string first. As you mentioned, and > can be escaped at the beginning of the preprocessPairs() function as it won't appear as we have above any mode. If you don't want unescaped semicolons appearing anywhere, you can also escape them.

Recognition pattern

We can then try to identify these patterns within the values ​​, and for each pattern we may need to run filtering again. We expect these patterns to be separated by some (or two) whitespace characters.

It should be okay to include support for multiline strings, which is an escaped newline.

Locales

We need to realize that we have at least two contexts to filter - HTML and CSS. When we include styles in elements, the input must be safe and it must be valid CSS. Fortunately, you're not including the CSS in the element's style attribute, so this is slightly easier.

Filtering based on value pattern

1. Strings surrounded by apostrophes - we don't care about anything but apostrophes and semicolons, so we need to find unescaped instances of these characters in the string and unescape them Escape
2. Same as above, just use double quotes
3. should be no problem
4. should be no problem
5. Basically no problem
6. This is the fun part

So points 1-5 will be very simple and most of the values ​​will be covered by the simple filtering and trimming ahead. With some additions (don't know what impact on performance) it might even do extra checks for correct units, keywords, etc.

But compared to other points, I think the relatively bigger challenge is point 6. You might decide to simply disable url() in this custom style, letting you check the input to the function, so for example you might want to escape the semicolon, or maybe even check inside the function again with a tiny tweak The pattern is for example calc().

in conclusion

In general, this is my opinion. With a few tweaks to these regular expressions, it should complement what you're already doing and give you as much flexibility as possible in typing CSS while saving you from having to tweak your code every time you tweak a CSS feature.

Example

function preprocessPairs(obj) {
  // Catch-all regular expression
  // Explanation:
  // (                                   Start of alternatives
  //   \w+\(.+?\)|                       1st alternative - function
  //   ".+?(?<!\)"|                     2nd alternative - string with double quotes
  //   '.+?(?<!\)'|                     3rd alternative - string with apostrophes
  //   [+-]?\d+(?:\.\d+)?(?:%|[A-z]+)?|  4th alternative - integer/decimal number, optionally per cent or with a unit
  //   #[0-9A-f]{3,6}|                   5th alternative - colour
  //   [A-z0-9_-]+|                      6th alternative - keyword
  //   ''|                               7th alternative - empty string
  //   ""                                8th alternative - empty string
  // )
  // [\s,]*
  const regexA = /(\w+\(.+?\)|".+?(?<!\)"|'.+?(?<!\)'|[+-]?\d+(?:\.\d+)?(?:%|[A-z]+)?|#[0-9A-f]{3,6}|[A-z0-9_-]+|''|"")[\s,]*/g;

  // newObj contains filtered testObject
  const newObj = {};

  // Loop through all object properties
  Object.entries(obj).forEach(([key, value]) => {
    // Replace <>;
    value = value.trim().replace('<', '\00003C').replace('>', '\00003E').replace(';', '\00003B');

    // Use catch-all regex to split value into specific elements
    const matches = [...value.matchAll(regexA)];

    // Now try to build back the original value string from regex matches.
    // If these strings are equal, the value is what we expected.
    // Otherwise it contained some unexpected markup or elements and should
    // be therefore discarded.
    // We specifically set to ignore all occurences of url() and @import
    let buildBack = '';
    matches.forEach((match) => {
      if (Array.isArray(match) && match.length >= 2 && match[0].match(/url\(.+?\)/gi) === null && match[0].match(/@import/gi) === null) {
        buildBack += match[0];
      }
    });

    console.log('Compare\n');
    console.log(value);
    console.log(buildBack);
    console.log(value === buildBack);

    if (value === buildBack) {
      newObj[key] = value;
    }
  });

  return newObj;
}

Please comment, discuss, criticize, and let me know if I forgot to touch on a topic that is of particular interest to you.

source

Disclaimer: I am not the author, owner, investor, or contributor of the sources mentioned below. I just happen to use them to get some information.

• https://www.w3.org/TR/css-values-3
• https ://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/05-Testing_for_CSS_Injection
• https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html