You don't have access to this class

Keep learning! Join and start boosting your career

Aprovecha el precio especial y haz tu profesión a prueba de IA

Antes: $249

Currency
$209
Suscríbete

Termina en:

2 Días
21 Hrs
30 Min
54 Seg

Otras reglas de prevención

5/13
Resources

How to prevent vulnerabilities when processing user text?

In the world of web development, security is paramount, and one of the practices that require the most care is the processing of user data. It is crucial to ensure that the text received is handled securely to prevent the execution of malicious code. The ideal strategy is to use that text exclusively for presentation purposes: display it as an avatar, a last name, etc., and use JavaScript methods intended exclusively for text processing.

Is it safe to use interpreters in our code?

Although in theory it is ideal to avoid running text through interpreters, in practice it is often necessary to process such text. To secure our site, we must:

  1. Validate the text: make sure it meets all the necessary criteria before using it.
  2. Clean up the text: Remove or transform parts of the text that may be dangerous.

Reducing dependency on operations that require text processing with an interpreter increases the security of web applications.

Which JavaScript methods are most dangerous?

There are several methods in JavaScript that are potentially dangerous when working with text strings. Some of them are:

  • eval(): Executes JavaScript code represented as a string. Although some libraries use it internally, its direct use is discouraged due to its inherent risks.

  • document.write(): Although popular in the past, it is currently being discontinued and presents security issues.

  • innerHTML and outerHTML: They offer the ability to insert HTML into the DOM, which is extremely dangerous as it can facilitate XSS (Cross-site Scripting) attacks.

In cases where reading data is necessary, innerText proves to be a safer option as long as the data has been validated and sanitized beforehand.

How to safely manipulate content in JavaScript?

For safe text manipulation, consider using:

  • textContent: allows you to read and write text securely, ensuring that malicious JavaScript or HTML embedded in the content is treated as plain text and not executable code.

What precautions should I take when receiving user data?

Receiving user data is not limited to forms. Other entry points include:

  • URLs and search parameters: Items such as location.hash.split() can expose applications to risk if the results are not handled carefully.

When working with technologies and frameworks such as React or Next.js, you need to question how this data is handled at specific points such as the router. For example, in Next.js the router query is used, but while this provides some security, it does not eliminate the risk entirely. Validating and sanitizing this data is still crucial.

With this solid foundation, you can protect your applications from common vulnerabilities. Continue to explore and learn secure practices to continue to grow as a web developer.

Contributions 1

Questions 0

Sort by:

Want to see more contributions, questions and answers from the community?

📏 Otras reglas de prevención

Ideas/conceptos claves

Node.textContent - Web APIs | MDN

Apuntes

Prevención

  • El texto siempre debe ser usado para fines de presentación
  • Entre menos utilicemos operaciones relacionadas con un intérprete, más seguridad tendrá el sitio
  • Si es usado para procesar datos (inputs), siempre debe ser validado y saneado
  • Existen varios métodos peligrosos y no tan peligrosos al utilizar cadenas de texto
    • eval ⇒ Recibe un texto y lo ejecuta en JavaScript
    • document.write, innerHTML, outerHTML
    • node.innerText*
    • node.textContent

Mediante la URL

location.hash.split("#")
location.search.split("?")
  • Cuando utilizamos parámetros en la URL de igual forma debemos tener cuidado con lo que se recibe
  • En react su equivalente es utilizar el hook useRouter()
const router = userRouter();
const currentAuthor = router.query.author
  • Next.js ya trae un query builder y es por eso que ya tenemos router.query si bien elimina o mitiga uno de los riesgos de XSS no nos asegura que el valor sea sano