10 Matching Annotations
  1. Oct 2020
    1. Yet it can be deceivingly difficult to properly encode (user) input

      They were talking about output encoding but then switched to input encoding? Did they really mean to say input encoding here?

    2. When processing untrusted user input for (web) applications, filter the input, and encode the output.
    3. Encoding is dependent on the type of output - which means that for example a string, which will be used in a JavaScript variable, should be treated (encoded) differently than a string which will be used in plain HTML.
  2. Apr 2020
    1. What we actually want to do is to escape content if it is unsafe, but leave it unescaped if it is safe. To achieve this we can simply use SafeBuffer's concatenation behavior:
    2. Our helper still returns a safe string, but correctly escapes content if it is unsafe. Note how much more flexible our group helper has become because it now works as expected with both safe and unsafe arguments. We can now leave it up to the caller whether to mark input as safe or not, and we no longer need to make any assumptions about the safeness of content.
    3. A common mistake is to see those escaped angle brackets, and "improve" the helper by making everything html_safe:
    1. 1- Validation: you “validate”, ie deem valid or invalid, data at input time. For instance if asked for a zipcode user enters “zzz43”, that’s invalid. At this point, you can reject or… sanitize. 2- sanitization: you make data “sane” before storing it. For instance if you want a zipcode, you can remove any character that’s not [0-9] 3- escaping: at output time, you ensure data printed will never corrupt display and/or be used in an evil way (escaping HTML etc…)