I am requesting Security Advisory coverage for the Node Alias Link Display module. The project adheres to Drupal's coding standards, avoids known insecure practices, and is maintained transparently via the Drupal.org infrastructure.

Node Alias Link Display [D10, D11]

This Drupal module provides a custom field formatter to display node links using their URL alias (e.g., /my-title) instead of the canonical path (e.g., /node/123). This is particularly beneficial for improving SEO and offering clean, user-friendly URLs in site content. The module enhances link presentation by leveraging Drupal’s path alias system without altering the underlying routing logic.

Project link

https://www.drupal.org/project/node_alias_link_display

Comments

iheb.attia created an issue. See original summary.

vishal.kadam’s picture

Title: Project application for Security Advisory coverage » [1.0.x] Node Alias Link Display
Assigned: iheb.attia » Unassigned
Issue summary: View changes
Issue tags: -security advisory coverage
berramou’s picture

I did a quick review, I didn't find any serious security issue but still need to sanitize alias and original parts before replacing, and maybe add $node->access() to check node access.
Something like:

if (is_numeric($nid)) {
  $node = $this->entityTypeManager->getStorage('node')->load($nid);
  if ($node instanceof Node && $node->access()) {
    $language = $this->languageManager->getLanguage($langcode);
    $node_url = $node->toUrl('canonical', ['language' => $language]);
    $alias = $node_url->toString();

    if ($alias !== "/node/$nid") {
      // Sanitize alias and original parts before replacing
      $safe_original = Xss::filter($original);
      $safe_alias = Html::escape($alias);
      $safe_url = Html::escape($url);

      return str_replace($safe_url, $safe_alias, $safe_original);
    }
  }
}
return Html::escape($original);
berramou’s picture

Status: Active » Needs work
vishal.kadam’s picture

Issue summary: View changes
iheb.attia’s picture


At this stage of the process, the alias and original strings are already sanitized. The plugin filter is executed after the node is built and its access is checked, so we can be confident that the node access logic has already been enforced upstream.

Also, note that the final output is passed through Xss::filter() after rendering, which strips any remaining HTML tags. So even if the alias or original contained HTML at some point, it will be removed before display, ensuring XSS protection.

Let me know if you still have concerns, but from what I see, the current flow already handles both access control and sanitization appropriately

berramou’s picture

Thank you @iheb.attia for your contribution and explications.
It's clear, since there is no other security issue, i will move this to fixed!

berramou’s picture

Status: Needs work » Fixed
avpaderno’s picture

Status: Fixed » Needs review

These issues are fixed only when the applicant gets the role that allows to opt projects into security advisory coverage. That can only be done by project moderators.

iheb.attia’s picture

rushikesh raval’s picture

Priority: Normal » Major

I am changing the issue priority as per issue priorities.

avpaderno’s picture

Priority: Major » Normal
Status: Needs review » Closed (duplicate)

Actually, this project does not have enough Drupal code, differently from the other one. We should continue with the other application.

avpaderno’s picture