I try to make sense out of an edge case scenario I just came across and would love to get some ideas around why this may happen.

On any CloudPage, if I add a GET or POST parameter with the value of <a or any alphabetic value leading with a < symbol, the CloudPage just hard fails and is not being rendered.

You can try it with a simple GET Cloudpage of empty content and add the parameter to the URL:


This also happen if you use POST:

<!DOCTYPE html>
    <form action="%%=RequestParameter('PAGEURL')=%%" method="POST">
        <input type="submit" value="<a" name="name">

This does not happen with > or any numeric value such as <3

  • Are you saying the problem happens even with the value correctly URI encoded? It seems like you are, from your second example. Clearly the first example is strictly wrong since encoding is required. For the post, you should use &lt;a for the value of the input I believe.
    – Phil W
    Nov 22, 2021 at 8:41
  • URLEncode does not work as shown above. HtmlEncode as with your example works but only for GET parameter in the URL because &lt;a only will be converted to <a on render. I am not aware of a native HTMLEncode method for SFMC. I could use SSJS REPLACE for each input value before sending it off but this also is known to do funny things. Also HTML forms are using application/x-www-form-urlencoded by default so the POST values is encoded.
    – shd.lux
    Nov 22, 2021 at 9:17
  • 1
    My first thought is that this is likely a security feature to help prevent code injection. I am gonna try to dig in and see, but this actually sounds like it is a good thing that they have in place. Nov 22, 2021 at 14:45
  • 1
    Although it looks like the official document stating this is gone or superbly hidden, this SFSE answer validates my above suspicion: salesforce.stackexchange.com/questions/116952/… Nov 22, 2021 at 15:05
  • Thank you Gorton - very interesting and it makes sense to prevent code injection but how would you do a form POST with a password containing <a? Of course if I would have full access to the login database of the service, I could hash it the same way as the password has been stored. However in my case I use an auth service which expect an unhashed password. Sure I could write up a Cipher logic and encrypt it with AES and decrypt before sending it to the auth service but we are using HTTPS for that reason to encrypt POST parameters on transmission....
    – shd.lux
    Nov 23, 2021 at 2:34

1 Answer 1


The answer to my question was answered in the comment section by @Gortonington.

this is likely a security feature to help prevent code injection: Marketing Cloud SQL Injection?

If you consider to build a form page which needs to modify the post parameters prior submit to make it work in CloudPages here is an example code.

<script runat="server">
        Platform.Load("Core", "1.1.5");

        // get parameter
        var submit = Request.GetQueryStringParameter('submit');
        var password = Platform.Function.Base64Decode(Request.GetQueryStringParameter('password'));

        if (submit) {

    <!DOCTYPE html>
        <script src="https://code.jquery.com/jquery-3.6.0.min.js" integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4=" crossorigin="anonymous"></script>
        <script type="text/javascript">
            $(function () {
                $('form[name="passwordForm"]').submit(function (e) {
                    var password = $('input[name="password"]');
                    var value = password.val();
                    var valueBase64 = btoa(value);

                    // Set the form value to the base 64 encoded version

        <form action="%%=RequestParameter('PAGEURL')=%%" method="POST" name='passwordForm'>
            <input type="password" value="" name="password">
            <input type="submit" value="submit" name="submit">

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .