Develop Reference

Preventing passwords showing in source code

I am doing a password manager web app (like LastPass etc), one of the things that has occurred to me is that after using PHP to retrieve the passwords from a db and decrypting them and then using JS to display them in the UI, the variables containing their passwords are visible if someone looks at the source code. Even if I did not use JS and used echo instead it would still be in the source code. Does anyone know of a, hopefully not too complex, way that can prevent the passwords from being in the source code?

If you're talking about the HTML source code, this is normal. But there is a few way to avoid it:
If you just want not to have it in your HTML when it is received by the user, then you can implement it via an Ajax request in javascript, to update the DOM with the text.
If you want that when the user do inspect on the page he doesn't see the password you can use an input and set in javascript the value of it. then you set the input as disabled so the user cannot modify it. You can even change the type as password when needed so it's displayed as ****** when you want to hide it.
Another way could be to add in javascript a css :after and tu put the value inside it. But it will still be visible somewhere I think.

You can use JavaScript to send an HTTP request (using xhr or fetch) to your backend, then you can manipulate the DOM to show the password.

custom form control custom client side validation in Kentico

We've created a custom FormEngineUserControl to capture date input using 3 text inputs for day/month/year.
On the server we override the bool IsValid() method which works fine and displays the error message if invalid.
However we want to use client side validation also, we can use a CustomValidator control and assign a ClientValidationFunction to call a JS method however this is not then combined with the server validation function and we end up with two validation messages, one that removes when client validation passes, and one that only disappears when the form is re-submit, basically rendering the client validation useless.
Is there no way to register a client validation method with a custom form control? that will then be combined with the server method and error label etc. ?

This should work pretty much like any other .net user control. How are you preventing further processing if the validator returns false? You might need to set StopProcessing property to true.
There a few similar topics which might address your porblem:
stop execution in Custom validator if it false
Custom validator fires but does not prevent postback

I don't think this is feasible as I'm not sure how you could combine client vs server side validation. You cannot ever disable server side validation. The client side validation is just there for better UX, its not secured by any means. The general idea this is used is that you disable form submission until all fields are verified on the client side. If the validation is the same on the server, you should not see the same error messages because otherwise it wouldn't go pass the client in the first place.
The way you could do this in Kentico is to use some custom js (or better yet some framework/library to help you with validation such as validate.js), give Kentico form some id/class and connect the form validation with your js and have each side (client/server) do its job.

How to ensure HTML input remains required?

If you create a form using HTML inputs and make the input required using the "required" attribute (<input type="text" required>), what is stopping a user from manually deleting the attribute by using their web browser's built in developer tools or by loading JavaScript by some other means (such as a bookmarklet)?
In other words, how can you ensure the required input remains required?

The client/browser has little control over the request that is sent to the server. A request can be constructed and passed to the server without involving a browser, therefore its the server side code's responsibility to ensure that the required parameters were provided with the request (as well as validate the parameters).

You need to consider a few things:
Everything on the client side can be modified by the client: nothing is stopping me from using my browser console or modifying the source code to change parts of your page, and you can't do anything to stop that. For instance, look how many upvotes your question has:
Obviously that doesn't actually do anything, but that's because all of the heavy lifting is done by Stack Exchange's servers.
Even if you make a field required, people can still fill in the field with a space or asdf and move on. Just because input is required doesn't mean that it is valid.
So, with that in mind, realize that you'll need to work on the server side to validate input. People can't mess with servers (easily) and it's the safest way to validate input. You'll need to deal with validation when your server receives the data because the client side is always vulnerable to user modification.

Use javascript to control some html fields of a form before submitting

Before submitting a form, i use javascript code (surrounded in PHP) in order to make locally some controls but sometimes javascript may not be enabled client-side.
The fact is that I have to check by pattern/regex each control of the form for example checking email, phone number,.. format so that user cannot enter anything haphazardly. Therefore, if javascript is not enabled, the form must not be submitted, even if all field are fulfilled out.
Therefore my question is to know if there is a tag or function which allow to perform what i want to?
Thank for your help

JavaScript runs client-side.
That means that users have FULL CONTROL over it.
Then, if they want to disable it, you can't do anything about it.
The only thing you should do is be sure that users with JS disabled will be able to submit the form too.
If you use JS to validate the form, be aware that users have FULL CONTROL over it, so they can send the form if they want, even if your code says that it's invalid.
The right way to do it is:
Be sure users without javascript can send the form
Implement client-side validation for users with javascript activation. This way they will have a better user experience (because can know if the data is invalid immediately) and is less server intensive (your server will have to validate less invalid forms).
ALWAYS validate the submited form server-side. Data coming from a client is always UNTRUSTED, even if you think you have validated it.

Is there a point of client-side validation of static info from a HTML form?

My question is regarding the user input that is received form a html form and is static one(by 'static' - I mean information from things like select options, radio buttons, check boxes). Should i do a client-side validation as i assume that the user can change my html code with tools like firebug.
Example:
my code:
<select>
<option>public</option>
<option style="display:none">private</option>
</select>
user's modification:
<select>
<option>public</option>
<option selected >private</option>
</select>
Should I validate this input in JS or leave it for the server-side validation?
I know that the user can manipulate JS also so I see no point in doing this kind of validation in JS.
My logic:
As this is a static info an ordinary(the good guy) user won't mess with it and therefor there is no need to check it.
If an evil user want to mess with my code he probably will know how to mix not only the HTML code but also the JS code, so again - no need of client-side validation for static inputs.
So am I right or should always have the full specter of validation on the client-side.
PS:I'm asking only for the client side, I do always/as well a server-side validation of all the users inputs/

Always validate your input server side.
It's nice to validate things in JavaScript because you can tell the user early that the input is incorrect.
A clever user can bypass any JavaScript constraint you place because you can always make your own requests.
From a time-efficiency point of view. It's not worth spending a lot of time trying to help the evil user by always trying to give a useful error message. If the server thinks input is invalid you can reply with "invalid input". If your JavaScript validation is good enough a regular user should never run into that error.