AI agents: the content index is at /llms.txt. Every page is also available as Markdown — send the request header Accept: text/markdown, or append .md to the page URL.
Xperience Docs

Cookie consent

We use necessary cookies (opens in a new tab) to run our website and improve your experience while browsing. Additional cookies are only used with your consent. You may revoke your consent on the Cookies Policy (opens in a new tab) page or in your browser at any time.

Configure (opens in a new tab)
  • Documentation
    InstallationUsing the Xperience interfaceDeveloping websitesConfiguring XperienceManaging usersSecuring websitesDeploying websitesManaging website contentMultilingual websitesMacro expressionsExternal utilitiesIntegrating 3rd party systemsCustom developmentE-commerce featuresOn-line marketing featuresRelease notes - Xperience 13Xperience terminology glossary
  • Tutorial
    Using the Xperience interfaceDeveloper tutorialBusiness tutorialResource hub for marketers
  • API Examples
    ConfigurationContent managementDevelopmentE-commerceOn-line marketingSocial media
  1. Home
  2. Securing websites
  3. Developing secure websites
  4. Macros and security

Macros and security


Was this page helpful?

Send us feedback Go back to top
  • Community Questions & Answers (opens in a new tab)
  • Contact support (opens in a new tab)

Macros are an essential part of Xperience. You can read more about them in the Macro expressions chapter. This page focuses on the security mechanisms and best practices related to macros.

Signing macros

Whenever a user saves a complex macro expression, the system automatically adds a security signature. This signature contains an identifier of the macro's author (the user name or an assigned macro identity) and a hash of the given expression.

You can recognize signed macro expressions by the # character, which the system automatically inserts before the closing %} parentheses when saving the text containing the macro:

  • {%CurrentSite.SiteID #%}

For illustration, a signed macro may look like this in the database:

  • {%CurrentSite.SiteID|(user)administrator|(hash)9056b7b76629a47a660c40cc2e5b0d92a13d0f9bce178847ca412c3a585552a1%}
  • {%CurrentSite.SiteID|(identity)GlobalAdministrator|(hash)e3402fe14374ab15d119dddbb6c831ce3d2ef55bd8e70ce8eb80994f4e6ad18b%}

Hashing is omitted when submitting very simple macros (e.g., {%FullName%}). Macros are signed only when they contain an indexer or a dot.

The system checks the macro signature when accessing an object through a different object (for example the user settings of a user object) and evaluates whether the user (identified by the signature) has permissions to execute the macro.

The best practice is to use the least privilege approach – submit macros signed by a user who has access only to the required objects and nothing else.

SQL injections

Macros can become part of SQL queries, for example in WhereCondition and OrderBy fields, which can lead to SQL injection vulnerability.

To protect from SQL injection, we recommend using the SQLEscape method when handling SQL macros:

SQL
WHERE UserName LIKE '%{% SQLEscape(QueryString.GetValue("test", ""))#%}%'

However, if you expect a different data type than string (for example an integer), you need to convert the macro to the correct data type. The SQLEscape method is useless in this case.

SQL
WHERE UserID = {% ToInt(QueryString.GetValue("test", ""), 0)#%}

Output encoding of macros

Macro encoding is an essential protection against XSS. You must encode output macros properly, unless you want to display some HTML code using the particular macro. There are several methods for encoding macros in Xperience:

  • {% UrlEncode(CurrentUser.FullName) %} – macro is encoded into the query URL.
  • {% HTMLEncode(CurrentUser.FullName) %} – macro is a part of standard page output text and text between HTML tags.
  • {% HTMLAttributeEncode(CurrentUser.FullName) %} – macro is a part of an HTML attribute
  • {% JSEscape(CurrentUser.FullName) %} – macro is a part of JS code.

Writing custom macro methods

When creating a custom macro method, you need to ensure security yourself. The macro engine cannot predict which data is accessed in the method, and thus cannot properly secure the method.

Unsafe macros

Query macros, cookie macros and data macros (information from the database, e.g. user display name) and their equivalent properties can be potentially dangerous. When you use these macros, you have to secure them against SQL injection and XSS.

It is NOT possible to gain access to user passwords using macros.

On this page

  • Signing macros
  • SQL injections
  • Output encoding of macros
  • Writing custom macro methods
  • Unsafe macros

Related pages

  • Macro expressions