모범 사례: 노드 JS 보안

프로그래머로서 우리는 웹 애플리케이션이 안전한지 확인해야 합니다.
이 짧은 게시물에서는 웹 앱을 보호하는 몇 가지 방법을 살펴보겠습니다.

모든 결함으로 인해 데이터, 노력 또는 프로그램 자체가 손실될 수 있습니다. 저는 Node J에 초점을 맞추고 있지만 이 원칙은 다른 언어에도 적용됩니다.

🥦 API 비밀은 절대 공유하면 안 됩니다.

프런트 엔드로 보내는 데이터를 과도하게 노출하지 마십시오.

위의 응답은 user successfully created 로 대체할 수 있습니다.

🥦 헬멧 사용

헬멧은 다양한 HTTP 헤더를 설정하여 Express 앱을 보호하는 데 도움이 됩니다. 묘책은 아니지만 도움이 될 수 있습니다. source

const helmet = require('helmet')
app.use(helmet())

🎯 헬멧을 사용하지 않으면 헤더가 이렇게 나타납니다.


🎯 헬멧을 사용하면 👇🏿처럼 보입니다.


이 두 줄의 코드는 웹 사이트의 민감한 데이터를 보호하는 데 도움이 될 수 있습니다.

🥦 더 이상 사용되지 않거나 취약한 버전의 Express를 사용해서는 안 됩니다.

더 이상 사용되지 않는 경고를 자주 받습니다.
패키지가 최신인지 확인하거나 최신 릴리스로 전환하십시오.

app.use(bodyParser()); //Now deprecated

🥦 환경 변수

내가 처음 웹 개발을 배우기 시작했을 때, 내가 받은 첫 번째 가혹한 경고 중 하나는 선임 개발자로부터 왔습니다.
"API 키 및 기타 정보를 안전한 장소에 저장하십시오. .env".

🥦 속도 제한기

애플리케이션을 안전하게 유지하려면
무차별 대입 공격에 대해 일종의 속도 제한을 구축해야 합니다.
Node.js의 rate-limiter 패키지를 사용할 수 있습니다.
npm install express-rate-limit

const rateLimit = require("express-rate-limit");
const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100 // limit each IP to 100 requests per windowMs
});

//  apply to all requests
app.use(limiter);

source

🥦 암호는 일반 텍스트로 저장하면 안 됩니다.

일반 암호를 해시된 암호로 변환하는 데 도움이 되는 라이브러리가 있습니다. bycrypt는 그러한 라이브러리 중 하나입니다.

const bcrypt = require('bcrypt');
const saltRounds = 10;
const myPlaintextPassword = 's0/\/\P4$$w0rD';
const someOtherPlaintextPassword = 'not_bacon';

최신 라이브러리를 활용하는 것이 중요합니다.

bcrypt와 bcryptjs의 차이점을 고려하십시오. 적극적으로 유지 관리되는 라이브러리를 사용하고 싶습니다.

고객에게 공유되는 정보의 양 제한

예를 들어 아래 코드에서 비밀번호는 사용자 { 비밀번호: 0 }에게 다시 전송된 데이터에서 제거됩니다. 이를 프로젝션이라고 합니다.

router.get('/me', VerifyToken, function(req, res, next) {

    User.findById(req.userId, { password: 0 }, function(err, user) { //{password: 0 is called projection i.e hide certain infos from the fetched data}
        if (err) return res.status(500).send("There was a problem finding the user.");
        if (!user) return res.status(404).send("No user found.");
        res.status(200).send(user);
    });

});

보안을 의식하는 한 가지 진술: 사용자에게 "사용자를 찾을 수 없음"메시지를 보내거나 암호가 올바르지 않다고 알려서는 안 됩니다.
이를 계정 열거 취약점(계정 열거 취약점)이라고 합니다.
이렇게 하면 다른 사람이 시스템에 사용자가 있는지 여부를 발견하여 스팸 목록, 피싱 및 기타 목적으로 정보를 활용할 수 있습니다.

단순히 제공된 자격 증명이 잘못되었거나 이와 유사한 것이라고 명시하는 것이 좋습니다.

결론

이것은 웹 앱에 보안을 추가하기 위한 기본 가이드일 뿐입니다.
서버 보안을 위한 추가 옵션을 살펴보십시오.

논의하다

온라인 지원을 보호하기 위해 어떤 다른 절차나 전략을 사용합니까?

참조

Best Practice-Security

읽어 주셔서 감사합니다