Develop Reference

Is it safe to bind password field to data object property in Vue?

This question is bugging me quite a bit.
Let's suppose I want to build a login component to use in my application (with Vue), where there are 2 expected input fields, one for the userID, the other for the password. Of particular concern in the context of this question is the password input field.
<input id="password" type="password" class="field-input">
I know you can do 2-way binding using v-model (and 1-way with v-bind), but the question is with password "should" you bind it to the data object in that way? Is it safe? Doesn't that mean the password is then stored in plain text in the data object? If that is not a safe way to do it then is there some other way?

With password "should" you bind it to the data object in that way?
Absolutely! According to the Vue documentation
Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases ... v-model internally uses different properties and emits different events for different input elements - text and textarea elements use value property and input event
Using the data function property below
data() {
return {
password: '',
}
}
Basically <input type="password" v-model="password"> is a short form of
<input type="password" v-bind:value="password" v-on:input="password = event.target.value">
This is like telling the computer,
on input (event), update the value of the password property.
You are merely storing the password in memory which you would send via a form (I assume).
Is it safe?
Absolutely! as long as you take other precautions such as using an input type of password (which you are) to prevent someone from snooping on the user's password as they type it, use HTTPS that will hash all details when going from client to server and as long as you use a POST request to send the password (via a form) with proper sanitisation (trimming the password value, escaping to reduce chances of injection attacks etc), proper validation (making passwords difficult to guess etc.), hashing (using bcrypt or any other hashing program) and storing the password on the server side (database) and some of the other best practices recommended by OWASP, you should be ok.
For more on OWASP authentication best practices, see [this] (https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
Doesn't that mean the password is then stored in plain text in the data object?
It is stored in memory but hackers don't have access to it as long as you send it via a POST request in a well validated and sanitised form over HTTPS and using the other precautions stated above.

Technically you can but it's best practice not to save password in client.
Use tokens. If you want some complexity and caveats, use JWT. But just use tokens. Like a list of securely generated bytes encoded as a string and then save that on that client as a cookie or localStorage and send that with all your requests.
When the user types in a username and password you hit you authorization API endpoint and if the credentials are good you create a session in your database and associate it to this secure token you made. When a request is made you can look up the session and make sure it’s still valid/not expired and you know what user it belongs to so they’re “authenticated.”
Also, Use HTTPS and read about authorization vs authentication.

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.

javascript security: prevent user from calling function from console? [duplicate]

I allow my users to favorite an update or a forum topic.
So when a user tries to favorite one of these i will send via Ajax 2 things, the item_id(update or topic) as id(ex. 1321313213) and its type("update" or "topic") as string.
However lets say someones tries to favorite an update with the id untouched but the type is changed to "topic"(via firebug or whatever else)...
This should not procceed since this combination is not correct... how can i assure that the item_id being sent is an update or a topic since this ID might co-exist in both tables???
Current solution:
Create a hidden input element and add as value 5 random characters (a-zA-Z0-9) and md5 type name(update or topic)
like:
$random_str = $this->my_model->generateRandomString(5);
<input type="hidden" value="<?php echo $random_str.md5("update"); ?>" id="type" />
so when i try to validate the data to check if it is an update or topic i split the type on the first 5 characters and later and check if the later characters are md5 hashed are update or topic and continue validation
I would like some help in case this can be altered as well...

Your server side script (PHP) must always assume it's getting bogus data. Never rely solely on javascript to handle any sanitization / verification.
If your javascript can determine if the job should be "update" or "topic", I'm sure your PHP can do that as well. Probably using a few more DB queries or some such, but that's the price you've got to pay.

Your are looking at the problem from the wrong perspective. Especially from You server side (PHP) code.
Your server gets data. It gets data which is something like that: user (from session), id and type. Your server needs to ask a question: is it valid data? If it is -- save it to DB; If it is not -- do not save it to DB. It is that simple.
You can look from this perspective: Your client side code is just one way to communicate with Your server. Another way is using web browser + firebug. It is perfectly valid usage of Your server side application. And Your PHP code should not care how request reaches it.
So if Your current code does not allow You in Your PHP code feel comfortable and freely decide if is it update or topic creation than Your need to change Your server side code (and perhaps DB schema) as well.
Your current solution is not good, because if I know how to use firebug I would probably find out that "9d9b68ac2b1de18d3712096354b3c3a5" means "topic" and "3ac340832f29c11538fbe2d6f75e8bcc" means "update".
I think Your are trying to invent Your own CSRF protection. So go on Internet and read about it.

Rate limit user input without using JavaScript

What are the possibilities for rate limiting user input without using JavaScript? The lesser round trips made to the server for this, the better.

Without JS, they only way to do this is to validate the input on the server and send back the page with error messages for the user.

You can use maxlength but need validate in backend too.

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.