> would love to see more tooling to lint and sanitize them before deployment
Sanitisation is one of two possible defences, the other being script execution controls or sandboxing. E.g., if you serve vector images on a web server, set a Content Security Policy header¹ for all your images that simply denies all scripting. You can also run it from a dummy domain ('origin') with nothing valuable on it (like how domains such as googleusercontent.com and githubusercontent.com are being used)
For sanitisation, DOMPurify² is the only widely used and tested library that I know of. It could use more bindings for other languages but, if you can call into it, it can go in your deployment pipeline. (Disclosure: I've worked with some of the people at Cure53, but not on this project)
You can also combine the approaches for defence in depth
The website has no open data license so this isn't usable for OSM, even if we wanted to. I just meant to propose collaborating on an existing platform where we already have a lot of data about physical features, rather than erecting an ephemeral platform for this special purpose
More than 200 hotels already on this website. Wouldn't this be much more useful as an OpenStreetMap tag so people can find and share these good/bad hotels in whatever front-end they like?
There does not seem to be a tag for it yet. That there are apparently hundreds of instances, and it being definitely something you'd want to select for, makes me think it's a good fit for OSM. Currently, hotels can already have tags like phone number, reception opening hours, WiFi fees, etc. It might even be a good fit for the toilets:* namespace, since this has overlap with toilets in (semi-)public spaces offering different levels of privacy
Or if you need records other than A/AAAA, like MX for delivering email: https://anyz.one
e.g. 10.2.3.4.anyz.one will refer the recursive resolver to query 10.2.3.4 for the answer to the query. You can also buy a domain and configure it to do that, but this is quicker
Sanitisation is one of two possible defences, the other being script execution controls or sandboxing. E.g., if you serve vector images on a web server, set a Content Security Policy header¹ for all your images that simply denies all scripting. You can also run it from a dummy domain ('origin') with nothing valuable on it (like how domains such as googleusercontent.com and githubusercontent.com are being used)
For sanitisation, DOMPurify² is the only widely used and tested library that I know of. It could use more bindings for other languages but, if you can call into it, it can go in your deployment pipeline. (Disclosure: I've worked with some of the people at Cure53, but not on this project)
You can also combine the approaches for defence in depth
¹ https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
² https://github.com/cure53/DOMPurify