Best way to hide/encrypt sensitive POST json in javascript console log
I have a simple web server (in python) with some API endpoints, and an HTML page with a form. When a user submits the form, the form data is sent to the web server via an ajax POST call via jquery. The API endpoint is HTTPs.
For one of the API endpoints, one of the parameters it takes is a password. I suppose the data transfer itself (from browser --> server) is secure as the POST is being done over https (and all the validation is being done on the server). However, I'd like to be able to obfuscate the password such that it will not show up in console logs. (Example - the javascript function which actually makes the api call, is a general function which can post to any endpoint. In a debug mode this function will dump the post json it's about to send. So in the case you're calling the endpoint which takes the password, the password would show up in plaintext in the log.)
I was just curious if there is a best practices way to achieve this? Something not overly complicated? Is it best to encrypt in the browser then decrypt in the server? Or a way to just make the logs show *** ? Note - I'm not concerned about the data being intercepted between browser and server, this is just about preventing anything showing up in the console logs in plaintext.
javascript passwords console.log password-encryption
asked Nov 20 '18 at 3:10
ffConundrumsffConundrums
19519
add a comment |
I have a simple web server (in python) with some API endpoints, and an HTML page with a form. When a user submits the form, the form data is sent to the web server via an ajax POST call via jquery. The API endpoint is HTTPs.
For one of the API endpoints, one of the parameters it takes is a password. I suppose the data transfer itself (from browser --> server) is secure as the POST is being done over https (and all the validation is being done on the server). However, I'd like to be able to obfuscate the password such that it will not show up in console logs. (Example - the javascript function which actually makes the api call, is a general function which can post to any endpoint. In a debug mode this function will dump the post json it's about to send. So in the case you're calling the endpoint which takes the password, the password would show up in plaintext in the log.)
I was just curious if there is a best practices way to achieve this? Something not overly complicated? Is it best to encrypt in the browser then decrypt in the server? Or a way to just make the logs show *** ? Note - I'm not concerned about the data being intercepted between browser and server, this is just about preventing anything showing up in the console logs in plaintext.
javascript passwords console.log password-encryption
asked Nov 20 '18 at 3:10
ffConundrumsffConundrums
19519
Might want to look into JWT (JSON Web Tokens).
– charlietfl
Nov 20 '18 at 3:24
add a comment |
I have a simple web server (in python) with some API endpoints, and an HTML page with a form. When a user submits the form, the form data is sent to the web server via an ajax POST call via jquery. The API endpoint is HTTPs.
For one of the API endpoints, one of the parameters it takes is a password. I suppose the data transfer itself (from browser --> server) is secure as the POST is being done over https (and all the validation is being done on the server). However, I'd like to be able to obfuscate the password such that it will not show up in console logs. (Example - the javascript function which actually makes the api call, is a general function which can post to any endpoint. In a debug mode this function will dump the post json it's about to send. So in the case you're calling the endpoint which takes the password, the password would show up in plaintext in the log.)
I was just curious if there is a best practices way to achieve this? Something not overly complicated? Is it best to encrypt in the browser then decrypt in the server? Or a way to just make the logs show *** ? Note - I'm not concerned about the data being intercepted between browser and server, this is just about preventing anything showing up in the console logs in plaintext.
javascript passwords console.log password-encryption
asked Nov 20 '18 at 3:10
ffConundrumsffConundrums
19519
I have a simple web server (in python) with some API endpoints, and an HTML page with a form. When a user submits the form, the form data is sent to the web server via an ajax POST call via jquery. The API endpoint is HTTPs.
For one of the API endpoints, one of the parameters it takes is a password. I suppose the data transfer itself (from browser --> server) is secure as the POST is being done over https (and all the validation is being done on the server). However, I'd like to be able to obfuscate the password such that it will not show up in console logs. (Example - the javascript function which actually makes the api call, is a general function which can post to any endpoint. In a debug mode this function will dump the post json it's about to send. So in the case you're calling the endpoint which takes the password, the password would show up in plaintext in the log.)
I was just curious if there is a best practices way to achieve this? Something not overly complicated? Is it best to encrypt in the browser then decrypt in the server? Or a way to just make the logs show *** ? Note - I'm not concerned about the data being intercepted between browser and server, this is just about preventing anything showing up in the console logs in plaintext.
javascript passwords console.log password-encryption
javascript passwords console.log password-encryption
asked Nov 20 '18 at 3:10
ffConundrumsffConundrums
19519
asked Nov 20 '18 at 3:10
ffConundrumsffConundrums
19519
asked Nov 20 '18 at 3:10
ffConundrumsffConundrums
19519
asked Nov 20 '18 at 3:10
ffConundrumsffConundrums
19519
asked Nov 20 '18 at 3:10
ffConundrumsffConundrums
19519
19519
Might want to look into JWT (JSON Web Tokens).
– charlietfl
Nov 20 '18 at 3:24
add a comment |
Might want to look into JWT (JSON Web Tokens).
– charlietfl
Nov 20 '18 at 3:24
Might want to look into JWT (JSON Web Tokens).
– charlietfl
Nov 20 '18 at 3:24
Might want to look into JWT (JSON Web Tokens).
– charlietfl
Nov 20 '18 at 3:24
add a comment |
2 Answers
2
active
oldest
votes
Don't log it.
As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.
It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.
answered Nov 20 '18 at 3:39
BradBrad
115k27232393
I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.
– ffConundrums
Nov 20 '18 at 16:12
1
side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.
– ffConundrums
Nov 20 '18 at 16:13
@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.
– Brad
Nov 20 '18 at 16:13
thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.
– ffConundrums
Nov 20 '18 at 16:16
add a comment |
If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:
$(your_password_field).serialize();
Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:
https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html
There is also an interesting discussion here:
SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt
answered Nov 20 '18 at 3:32
Bruno MonteiroBruno Monteiro
519
Can I please have a feedback on why this answer was not useful?
– Bruno Monteiro
Nov 21 '18 at 19:41
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53385660%2fbest-way-to-hide-encrypt-sensitive-post-json-in-javascript-console-log%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Don't log it.
As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.
It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.
answered Nov 20 '18 at 3:39
BradBrad
115k27232393
I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.
– ffConundrums
Nov 20 '18 at 16:12
1
side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.
– ffConundrums
Nov 20 '18 at 16:13
@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.
– Brad
Nov 20 '18 at 16:13
thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.
– ffConundrums
Nov 20 '18 at 16:16
add a comment |
Don't log it.
As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.
It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.
answered Nov 20 '18 at 3:39
BradBrad
115k27232393
I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.
– ffConundrums
Nov 20 '18 at 16:12
1
side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.
– ffConundrums
Nov 20 '18 at 16:13
@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.
– Brad
Nov 20 '18 at 16:13
thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.
– ffConundrums
Nov 20 '18 at 16:16
add a comment |
Don't log it.
As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.
It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.
answered Nov 20 '18 at 3:39
BradBrad
115k27232393
Don't log it.
As you said, the data is safe in the transport. If the issue is just with the logs, simply fix the logs so you're not logging sensitive data.
It's also important that your log files are kept as secure as the rest of your system. A great deal of security-related information can be derived from raw log files.
answered Nov 20 '18 at 3:39
BradBrad
115k27232393
answered Nov 20 '18 at 3:39
BradBrad
115k27232393
answered Nov 20 '18 at 3:39
BradBrad
115k27232393
answered Nov 20 '18 at 3:39
BradBrad
115k27232393
115k27232393
I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.
– ffConundrums
Nov 20 '18 at 16:12
1
side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.
– ffConundrums
Nov 20 '18 at 16:13
@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.
– Brad
Nov 20 '18 at 16:13
thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.
– ffConundrums
Nov 20 '18 at 16:16
add a comment |
I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.
– ffConundrums
Nov 20 '18 at 16:12
1
side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.
– ffConundrums
Nov 20 '18 at 16:13
@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.
– Brad
Nov 20 '18 at 16:13
thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.
– ffConundrums
Nov 20 '18 at 16:16
I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.
– ffConundrums
Nov 20 '18 at 16:12
I can fix the logs for now and just not log it. But another worry I had was, lets say somewhere in the future, someone innocently adds a print in the server which dumps the payload. Anyone who now visits the site is having their password exposed in plaintext. Even if the logs are secured it's now visible to that person who made the change. I guess the idea is that - if they were nefarious and have access to the code base, they could always change up anything they want to get that info. I'm more worried about an innocent change that ends up revealing the passwords to someone.
– ffConundrums
Nov 20 '18 at 16:12
1
1
side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.
– ffConundrums
Nov 20 '18 at 16:13
side note - good point about securing the logs in general, I hadn't put much thought in to this, which is something I will do now.
– ffConundrums
Nov 20 '18 at 16:13
@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.
– Brad
Nov 20 '18 at 16:13
@ffConundrums Adding a layer of obfuscation doesn't change that fact. If someone breaks your code and dumps out secrets, that's what happens. All you'll do with layers of obfuscation is make development harder while adding a false sense of security.
– Brad
Nov 20 '18 at 16:13
thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.
– ffConundrums
Nov 20 '18 at 16:16
thanks. What you're saying is the perspective I'd started reading about after I posted this. Maybe I just need to digest the perspective a little more.
– ffConundrums
Nov 20 '18 at 16:16
add a comment |
If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:
$(your_password_field).serialize();
Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:
https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html
There is also an interesting discussion here:
SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt
answered Nov 20 '18 at 3:32
Bruno MonteiroBruno Monteiro
519
Can I please have a feedback on why this answer was not useful?
– Bruno Monteiro
Nov 21 '18 at 19:41
add a comment |
If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:
$(your_password_field).serialize();
Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:
https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html
There is also an interesting discussion here:
SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt
answered Nov 20 '18 at 3:32
Bruno MonteiroBruno Monteiro
519
Can I please have a feedback on why this answer was not useful?
– Bruno Monteiro
Nov 21 '18 at 19:41
add a comment |
If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:
$(your_password_field).serialize();
Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:
https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html
There is also an interesting discussion here:
SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt
answered Nov 20 '18 at 3:32
Bruno MonteiroBruno Monteiro
519
If the communication is already HTTPS and you are not worried about the data being intercepted, then you can probably use something like serialization:
$(your_password_field).serialize();
Another idea is, if you are using some framework with your Python Server, check their documentation. This post, for example, shows how to use serialization with Django:
https://simpleisbetterthancomplex.com/tutorial/2016/08/29/how-to-work-with-ajax-request-with-django.html
There is also an interesting discussion here:
SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt
answered Nov 20 '18 at 3:32
Bruno MonteiroBruno Monteiro
519
answered Nov 20 '18 at 3:32
Bruno MonteiroBruno Monteiro
519
answered Nov 20 '18 at 3:32
Bruno MonteiroBruno Monteiro
519
answered Nov 20 '18 at 3:32
Bruno MonteiroBruno Monteiro
519
519
Can I please have a feedback on why this answer was not useful?
– Bruno Monteiro
Nov 21 '18 at 19:41
add a comment |
Can I please have a feedback on why this answer was not useful?
– Bruno Monteiro
Nov 21 '18 at 19:41
Can I please have a feedback on why this answer was not useful?
– Bruno Monteiro
Nov 21 '18 at 19:41
Can I please have a feedback on why this answer was not useful?
– Bruno Monteiro
Nov 21 '18 at 19:41
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53385660%2fbest-way-to-hide-encrypt-sensitive-post-json-in-javascript-console-log%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Might want to look into JWT (JSON Web Tokens).
– charlietfl
Nov 20 '18 at 3:24